One aspect of getting used to modern version control

I've spent a very long time using RCS as a sysadmin. In that time, certain things about how it works have just gotten ingrained in my hindbrain, to the level where I don't think about them consciously; they just are. Now that we're slowly moving away from RCS and to modern version control systems, I sometimes wind up running into bits of this that are no longer true, where I have to let how stuff works in modern version control gradually soak into my mind until old reflexive assumptions get dissolved.

One of them is the idea that committing things does not change the files that I am committing. Some of you may be going 'well of course it doesn't', but this is not how it works in RCS; when you commit a file in RCS, RCS removes and then recreates the file. For developers this may not be something that's very important, but it can really matter for sysadmins; among other things, anything that modifies live files makes us nervous.

(This also means that committing a file can change the file ownership, which is important when you absently ci a file as root or are working in a shared directory with group permissions.)

Modern version control systems don't do this; making a commit may change the repository, but it does not change the live file itself. This makes commits much less twitch inducing to sysadmins and much more like actual backups. Forgetting this difference makes me more twitchy about making commits than I should be and leads to occasional embarrassing mistakes.

(It also means that it is much less of an impact to set up an initial repository than it is to do the equivalent in RCS; with a modern VCS, it is effectively the same as making a tar or rsync or whatever backup of the files.)