Fri, 18 Jun 2004

Version control systems

I’ve been thinking about version control lately and am now in the middle of choosing the software that I’ll use in the future. I began with SCCS way back when I was doing everything on AT&T systems. When I made the move to BSD, I found that SCCS was no longer an option; fortunately, RCS was provided and it was a SMOP (with awk) to convert our s.foo files into foo,v files complete with revision history. The RCS way is similar to the SCCS way, so this transition was largely painless.

Later, for all the obvious reasons, I considered CVS. It did some of the things I wanted done, albeit in some cases inelegantly; but back then it was really slow and it had some design and implementation issues that were hard to live with. On top of that, the CVS model—copy/modify/merge, versus RCS’s lock/modify/unlock—although sound in principle seemed unlikely to be a success with the programming teams I had at my disposal at the time. I decided to stick with RCS, although I did play with CVS from time to time.

Now, no longer having to deal with those programming teams of the past, and having different needs of my own—in particular the need to be able to modify source from diverse locations—it seems that it’s finally time to move on to something in the CVS family.

And, as seems to happen, this is a field that’s seen quite a lot of activity in the last few years. CVS itself has been significantly improved, although it’s not safe to use vendor-supplied CVS servers because of the semi-constant flow of security issues. And there are several new kids on the block, most of which I have evaluated to some degree. I discarded some contenders quite quickly because of licensing issues and/or commercial status. For me, it’s critical that I not lose any of the important features of my current RCS setup; that means free software and open standards of data storage are non-negotiable. Others were crossed off the list because they were dead or dying. The real contenders came down to CVS, arch, and Subversion.

In some ways, arch is attractive; but it has two issues that made me turn away from it: (a) absurd file-naming that renders command-line use difficult; (b) an overall model that is sufficiently different from CVS that it’s going to be non-trivial to learn.

CVS is very tempting: it’s familiar to most people, including me; it has been around for ever; it’s trivial to move an RCS archive under CVS, even if the history will still only be as good as it was under RCS. Installation, even if you want to build it from source so as to keep ahead of the security problems, is simple. But there are real reasons why people have designed and built newer systems and some of those are to do with fundamental problems in the CVS design.

Subversion was specifically designed to be the successor to CVS and it has addressed the CVS problems fairly well while going out of its way to be compatible with CVS—at least from the user perspective. I don’t think it’s perfect—and there are things about the design that I don’t like—but it seems to be the closest to what I need. My two big concerns with Subversion are its reliance on Berkeley DB-4 for its storage and the vast array of dependencies on other software.

With CVS, you always knew that your data was fine, no matter what version of CVS you upgraded to. As soon as you use somebody’s database, you become a prisoner of their incompatible data storage with every new release. At the least, you have to have the old database software available so you can “dump” the old data in a portable format; and then you have to install the new database software and “load” the data. And, while you’re doing that, you have to ensure that nobody is trying to update anything. So this is a negative; and it’s one area where arch and CVS win.

I haven’t actually installed Subversion yet, but I have edited the install file to remove the Windows-related material; I still have ten A4 pages to read and deal with and about a million other pieces of software to install first. That really sucks. I’m planning to work my way through it, unless one of the dependencies turns out to be a show-stopper, and to setup a test repository. If I get that far, and if nothing bad happens, I expect to be running Subversion fairly soon. Watch this space …

Posted at: 14:35

Path: /software/discuss   |  permalink