Volume 10, Issue 69; 19 Jul 2007; last modified 08 Oct 2010

The version control system, not my personality.

The moment I learned that such a thing as a “version control system” existed, I was hooked. Over the years, I've used a few. I started with RCS then moved to CVS. I used ClearCase for a while. (At the time, I was working remotely over dialup. Let's just say that ClearCase was not optimized for that scenario and leave it at that.) I've done a Perforce checkout or two, for something TeX-related as I recall, though I can't really claim to have used it.

A few years ago, I switched to Subversion. Atomic commits. The ability to rename files and directories. Atomic commits. Versioned metadata. Atomic commits. I've been very happy with it. Especially the ability to make atomic commits.

A version control system is absolutely imperative if you're working collaboratively. There's really no other practical way to manage multiple developers updating the same code base.

But I use a version control system for everything that I do. I recommend that you do the same. I manage papers and projects that only I touch with Subversion. Heck, I have my whole home directory checked in.

Using version control for my own stuff has two obvious benefits. First, it protects me from the single most likely to fail component of my work environment: me. If some line of editing turns out to be a complete dead-end, you can just throw it away and check out the “last good” version. Second, it provides automatic backups. Well, sorta.

You see, I work disconnected from the net fairly often (think airplanes, vacations, etc.) and I really don't like to be unable to check stuff in. It just increases the window of opportunity for me to screw up and if that window gets big enough, I will.

In order to make it possible to work without an internet connection, I keep a lot of stuff checked into repositories on my local disk. So, yeah, if I rm * (instead of rm *~) in some directory, I can recover. But if the disk fails or the laptop is stolen, I'm hosed. Oh, I have proper backups, but they could be a few weeks or a month old. You want to lose a month's work? Neither do I.

This is where distributed revision control systems come in. Instead of a central repository that you have to be connected to, they work peer-to-peer. One practical consequence of this is that you can do check-ins, commits, or any other action while you're disconnected. The next time you are connected, you can “push” these changes to your peers.

I've been interested in trying one of these systems for a while (there are several). Since it looks like OpenJDK will use Mercurial, I figured that would be a good place to start.

It was fairly straightforward to setup Mercurial on my web host and create some repositories. With some trepidation and a few days hacking, I've converted the source for,, and even to Mercurial.

So far, it's been pretty painless. There are Subversion-to-Mercurial conversion tools, so I didn't loose any of my history. I have a few scripts that extract information from the commit logs; those had to be changed to work with Mercurial. I rely on keyword substitution (the $Date$ keyword provides the last-updated date), so I had to get and install the right Mercurial extension for that. It turns out that Ubuntu has not-quite-the-most-recent Mercurial release, so it took a couple of email exchanges with the author of the extension to get it working.

Then I just had to wait for my laptop to rebuild everything. Seems to have succeeded overnight. If you see something that looks screwed up, please do tell me.

(Before you hit the “add comment” link, yes I know, I could have accomplished the same goal, probably much more easily, with svnsync. But I wouldn't have learned anything practical about distributed version control that way, would I?)


svk is pretty good for online/offline stuff against svn, but yes, using a real dvcs is better.

—Posted by David Terrell on 20 Jul 2007 @ 01:10 UTC #

sounds like you have a similar history to me, though I started with SCCS and have had detours via PCVS (ugh!) and Continuus (double ugh!) SourceSafe (expletive deleted) and StarTeam (I'll get me coat) all flavors of much the same thing. Maybe we're both ready for git?

—Posted by Paul Downey on 20 Jul 2007 @ 08:40 UTC #

I'm also use mercurial for my own projects - writings, codings & home page. I had selected it due crossplatform - now i'm using it between MacOSX, Linux & Windows, and all works fine. Exchange of data happens via usb flash.

—Posted by Alex Ott on 20 Jul 2007 @ 10:12 UTC #
$ svk mirror //mirror/example
$ svk cp //mirror/example //local/example
$ svk co //local/example
$ cd example
$ svk ci -m "Some local commits."
$ svk push
—Posted by Noah Slater on 20 Jul 2007 @ 04:51 UTC #

I also experimented with SVK for awhile (because I do in fact need to be able to sync with some remote Subversion repositories). It works as advertised, but be warned that it's awfully slow (at least on my 2.0GHz Intel MacBook). I'd still like to try out git and Mercurial sometime soon to see if their performance is any better.

—Posted by Lyle Johnson on 20 Jul 2007 @ 07:52 UTC #

I considered SVK, too. In the end I decided I really wanted to try Mercurial (in preparation for working on OpenJDK, if nothing else).

So far, it seems to work fine. The only thing I'm having trouble getting used to is that 'hg status' gives you the status of the whole repository; you have to explicitly say 'hg status .' if you only want to see the status of the current directory. But that's just a design choice and I can see both sides.

I'm also finding the one, top-level .hgignore file a little funky. Subversion's notion of properties is really nicer.

—Posted by Norman Walsh on 20 Jul 2007 @ 08:01 UTC #

I have a similar history of version control systems, and resently I've started using Monotone, which i quite like (even though it's missing keyword substitution).

A summary description of Monotone sounds rather similar to what you say about Mercury; it's peer-to-peer to the core (everything is cryptographically signed, so you can even have people you don't trust with commit privs, and someone you do trust can then sign their actual commits if they are good).

—Posted by Rasmus Kaj on 23 Jul 2007 @ 09:30 UTC #

Actually, I have been converting SVN repositories to Mercurial as well, but it turns out to be a very nice to have a single list of ignores for the whole repository/working dir. Easier to check what I should copy manually...

—Posted by Manuzhai on 24 Jul 2007 @ 06:59 UTC #

I do see something that seems screwed up: at the bottom of this page is a line that says "Last modified: Sat, 01 Jan 2005". I don't know what it's trying to say, but it's either wrong or extremely confusing. (I don't know if this has anything to do with your move to Mercurial, though.)

I'd be interested in another post in a couple of weeks, saying whether you still like Mercurial.

—Posted by Carl Witty on 31 Jul 2007 @ 04:33 UTC #

Nice catch, Carl. The last modified date was formatted incorrectly because the $Date$ keyword substitution of Mercurial differs from Subversion. That's fixed now and I'm rebuilding (all) the HTML.

—Posted by Norman Walsh on 02 Aug 2007 @ 02:23 UTC #

I too had thought the OpenJDK project would go with Mercurial.

In case you hadn't noticed, the OpenJDK source has been published in a SVN repo: (despite the fact that I can't find an announcement of any sort).

—Posted by Jamie on 10 Aug 2007 @ 09:18 UTC #