I recently investigated version-control systems for personal use. I didn't spend a lot of time on any particular one, just enough to absorb the general ideas (or at least, I think so). I knew I wanted to step away from CVS, but I didn't know where to go. Simplicity was my strongest desire, although I do also have some need to manage changes both at home and at a client site.

The systems I looked at:

* subversion : http://subversion.tigris.org
* arch : http://wiki.gnuarch.org
* darcs : http://www.darcs.net

Executive summary: I'm using darcs. Read the flipside for my reasons.

+ Subversion (svn)

Subversion is the closest system in spirit to CVS. You set up a centralized repository and check code in and out. Subversion manages whole trees -- that is, the state of a directory tree can be versioned, and revisions include data about added, deleted, and moved files. (This is very different than CVS, where changing a project's directory structure is a real pain.) Branching in svn is easy, merges not so much (or so I'm given to believe); but for my own purposes branch/merge is not all that important.

I pretty much felt right at home with Subversion immediately. I set up a repository and checked some stuff in (after making a backup, natch). Checkouts, changes, checkins, history, all pretty much work as I expected. The only reason that I even looked at anything else was the following annoyance:

> cd my-projects
> svn import project1 file:///rpeository/project1
> # No problem so far...
> cd project1
> emacs some-file.py # Edit edit edit...
> svn commit
ERROR: this directory is not a working copy.

I don't know why I didn't expect this; CVS "works" the same way. Importing a project does NOT add the svn metadata to the project tree, so you have to move your project dir out of the way and do a "svn checkout" to get a copy you can actually make changes to and commit.

I thought I remembered that there was some version-control system that worked directly on the source tree, keeping the repository in a local subtree. That would be really convenient, I thought, so I started looking around, and found Arch.

+ Arch

Arch is a very different beastie from svn; I'm certain I don't even understand all the differences. But there are two fundamental ones:

1. In svn, a commit essentially makes a snapshot of the working tree. There is not a convenient way to separate distinct changes commited in a single commit operation. In contrast, Arch uses "changesets", which are essentially patches, and permits changes within a changeset to be applied and merged in various ways.
2. In svn, all checkouts and commits are made to a single centralized repository. The repository contains the "master" version of a project; the checked-out trees are just "working copies", which must be committed before anyone else can see them. In stark contrast, Arch is a completely distributed system: every user's Arch repository is essentially the same as any other, and changesets can be pushed around among different repositories at will.

I don't think I really need the advanced merging capabilities of Arch, but the distributed-repository aspect is pretty interesting. I have a single private client for whom I've written some web applications, and until recently there was no secure network access between the client site and mine. This meant that managing changes to the on-site code, or distributing new code, was really a pain (burn a CD, truck-net down to the client, etc). Now I've arranged secure network access, so I was planning to set up a CVS or svn repository. But the idea of keeping a repository at *both* sites and propagating changesets at will is seductive. (Though it occurs to me that there could be potential to shoot big old holes in my feet, too.)

So I really wanted to like Arch, but I really didn't. The main reasons for that are, first, Arch has what seems to me an unnecessarily complex command set, and it's hard to ignore parts of it that you don't (think you) need. And second, Arch likes to give things (like repositories and projects) really-really--long-names--with-different-components--delimited--by-hyphens. I didn't really get the need for that, and it really annoyed me after only a short while. Also, like svn, it's necessary to set up a repository outside the tree being managed, although Arch does allow immediate commits from an imported tree. So it pretty much fixed the things about svn that annoy me, but annoyed me with some other stuff.

Then, more or less at random, I ran across a reference to darcs.

+ Darcs

As far as I can tell, the working models behind Arch and darcs are very similar. Darcs is apparently based on an "algebra of patches", and is implemented in Haskell http://www.haskell.org, which gives me a little thrill :-) But conceptually, it seems pretty similar to Arch, in that you "record" change-sets, rather then snapshotting a project. And darcs is fully distributed, and all repositories are co-equal.

In execution, darcs really wins. For example, importing a project into an Arch repository is a lengthy affair, requiring a number of commands that don't make intuitive sense to me. You have to create a project, manually add files and directories (there doesn't seem to be a recursive add command in Arch), create a log file manually, edit the logfile, and commit changes -- just to get your freakin' code into the repository. Darcs, on the other hand, gets the job done in three commands: initialize, recursive add, commit. And a trivial shellscript automates that process in short order.

Furthermore, darcs doesn't require any repository outside the tree being managed: the repository lives in a _darcs directory created at the root of the tree, and *only* there. So un-darcsifying a project is simple: move the _darcs dir away.

Because of the self-contained repository, darcs doesn't need complicated branching commands. You wanna branch? Make a copy of your source tree, and you're done. You can push patches between local source trees using exactly the same commands you would use to push patches to remote repositories.

Darcs is very clean and nice, and I think I'll stick with it for a while.