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.

(This entry was sparked by Aristotle Pagaltzis's comment on my previous entry.)