Sysadmin versus developer uses of version control systems
Here is a thesis: sysadmins use modern version control systems
differently than developers. Specifically, sysadmins generally use VCSes
for documentation, while developers use them for development. By this
I mean that when sysadmins make a commit, it's for something that is
already in use; for example, you change a file in
/etc and then commit
in order to document when and why you made the change.
(This is certainly our local sysadmin usage of version control, but I think it is more than just us, especially given things like etckeeper.)
There are a number of important features of modern VCSes that are basically irrelevant if you are only using them for post-facto documentation. One obvious example is cherry-picking only some changes to commit; because all of the changes are already live, committing only some of them means that you are not documenting some active changes.
(There is some point to the ability, but needing to do it generally means that either someone forgot to commit several changes or that there was a crisis in a mixed directory.)
Sysadmins can use VCSes in a more development mode, but I think that it is somewhat foreign and is certainly going to take not insignificant amounts of work. (Consider the problem of testing your changes before you deploy them into the live version of the repository, for example.)
(Also, sometimes sysadmins do development work, both on code and on configuration files, and so use VCSes in the conventional 'developer' mode.)
I think that another way of putting this is that for sysadmins, the checked out files are the real thing and the repository is only their shadow copy. For developers, it is the reverse; the checked out tree is the shadow and the real thing is the repository.
Mercurial versus git for sysadmins, or why we picked Mercurial
I've recently managed to persuade my co-workers to start migrate away from doing version control with RCS and to using a modern VCS (which has made me think about various issues). Specifically, I picked Mercurial, which I think is one of only two sensible options right now (the other being git).
I'm perfectly prepared to believe that git has important aspects that make it technically superior, and that git has more power for doing sophisticated things that matter for serious development. But for us, all of that pales next to a very important property of Mercurial: it's really easy to tell my co-workers how to use Mercurial. Without caveats and 'watch out for this mistake' and 'never forget this argument or odd things happen'.
We have simple needs; point in time snapshots, the ability to see what we changed, and perhaps to write log messages about it that will be preserved for later use. I can teach people how to do this in Mercurial in a few simple commands. Git is, how can I say this nicely, not quite as simple, and it looks much more intimidating. (Such perceptions count a lot when you are trying to sell a new way of doing things to nervous co-workers.)
And, since we have such small and simple needs, any technical advantages and sophisticated features are essentially irrelevant. Git may be better than Mercurial, but either of them are good enough for our modest needs. So Mercurial's simplicity of use wins the day.
(I have found myself tilting this way for personal use as well. Git may be a great system, but it's still intimidating. Mercurial is much less scary. I somewhat regret this, because I really do want to someday use git for more than tracking the Linux kernel, so that I can get properly familiar with it. (Of course the answer to this issue is to just force myself to use git for my next project.))