RCS versus modern version control systems

November 22, 2009

Here is something that may shock people: we're still maintaining systems files with RCS. And I maintain that this is not as crazy as it sounds, once you dig under the surface, and that system administration is one of the last places where RCS is sensible some of the time.

For all their myriad benefits, the drawback of modern version control systems is that they really want to be used on whole directories (or directory hierarchies). This is generally pretty okay for source code, where you have directories that consist almost entirely of interrelated files, but system administration has lots of situations where either much of a directory's contents will not be managed by your version control, or the files that you are managing in your VCS are not related at all apart from being in the same directory on the same system.

(/etc is the canonical example of both situations. Yes, I know about things like etckeeper; I honestly think that they're uncomfortable hacks.)

For all its disadvantages (and it has significant ones), RCS's great virtue is that it is a single-file version control system, one that manages individual files instead of entire directories. Thus, it's both easy and mindless to put just one file in some random directory under version control. You don't have to set up an elaborate system or remember to carefully sidestep much of what your VCS defaults to doing; instead you can just do 'mkdir RCS; ci -l <file>' and not worry about it.

(And there is the benefit of less taxonomy, in that you don't have to decide what level of a directory hierarchy you should set up as the repository root. Quick: do you make all of /etc a repository, or do you want separate repositories for /etc/thing1, /etc/thing2, and so on?)

Sidebar: how I would get around the cluttered directory problem

What currently strikes me as the best solution is something that I saw in the Mercurial documentation recently: just tell the repository to ignore all files except those you've explicitly added. This basically turns your VCS into an easier to use version of RCS, where the equivalent of 'mkdir RCS' is to initialize a repository that ignores everything by default.

This doesn't deal with all of the VCS problems, but it gets you part of the way.


Comments on this page:

From 98.223.162.254 at 2009-11-22 18:33:58:

An excellent point, and one I hadn't considered. The counter-argument is that is most cases, you're probably not using version control on a machine's local files. In most cases, you're probably versioning configuration files that get managed by something like CFEngine or Puppet. In that case, RCS is more a hindrance than a help. For one-off systems or files, RCS is definitely the least complicated option, but that's more of an edge case in most setups I've encountered.

By cks at 2009-11-23 00:55:48:

For locally sensible but peculiar reasons, we are pretty much not using anything in the Puppet/CFEngine class, and do wind up not infrequently maintaining and versioning files in scattered directories that are not ideal for whole-directory version control.

(The more I look at converting some of what we're doing over to modern whole-directory VCSes, the more I think that you want to lay things out in your local files area somewhat differently for such VCSes. But that's another entry.)

Written on 22 November 2009.
« An update on faulted ZFS spares
My current unhappy thoughts on Fedora 12 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 22 01:28:50 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.