I have seen the future of free distributed revision control systems

And it is Mercurial.

I have used BitKeeper for several years, and it is quite simply a fantastic piece of software. But for non-commercial projects, at least if I want to collaborate with other people, it is no longer an option. BitMover will make the “free” version of BK unavailable from July 1.

The result is that many people are now casting about for BK replacements.

Here is my brief, skewed summary of the free distributed revision control world.

• Subversion is out of the running. It’s not distributed, it’s massively overengineered and fragile, and it has as many sketchy entanglements as a submariner on a weekend’s shore leave.
• SVK is built on top of Subversion. I am biased against it because Subversion is such a huge teetering pile of jelly. Adding even more complexity to it does not a confident prospective user make. SVK is at least fairly popular.
• GNU Arch is popular with the raving lunatic set. It’s impossibly slow and space-hungry, has a horrible UI, drops prominent file turds in every directory, forces bizarre working practices on its users, and it smells bad.
• Codeville is Bram Cohen’s (he of BitTorrent fame) pet revision control system. It has a cryptic UI and sparse, out-of-date documentation. It requires a server process to do anything useful, which is irritating. The user community is negligible in size, development is fitful, and Bram is not exactly a diplomat.
• Cogito is the sort-of-SCM layer on top of Linus Torvalds’s git. It is currently minimalistic and difficult to use, but has a number of very enthusiastic developers. Unfortunately, the headlong pace of development is such that it’s effectively impossible to keep up with. Originally, Linus touted git as being fast, but it achieves this speed through profligacy in disk, memory, and network usage, and by having a tiny feature set.
• I have almost no opinion of Monotone, though Jeremy thinks quite highly of it. It is actively developed. It supports some useful features you’d expect to be present in other distrubted SCMs, but that many don’t yet have, such as renaming of files and directories, and merges across renames. Weirdly, although it supports renaming, it just socks away a record that a rename has occurred, and forces you to do the rename yourself.

Although Mercurial is currently small and clearly in the early stages of development, it has a number of things going for it:

• Its storage representation is compact.
• The documentation is simple and clear.
• It has built-in command help; it is terse, but useful.
• It is written in Python, and the source is cleanly put together, so it is easy to hack on.
• It can import git repositories, but uses about a tenth the space that git does.
• It doesn’t impose peculiar practices on the unfortunate user for perverse purposes.

That said, at the time of writing, Mercurial is missing a pile of features:

• File and directory renaming, deletion and undeletion. Transparent merges across all of these changes.
• Mutable per-working-directory config data. Mercurial creates a .hg/hgrc config file if, and only if, you copy a repository using hg init source. Afterwards, you must edit this file by hand, assuming you even find out that it exists. I only found it by accident, while reading the source.
• The notion of repositories holding entirely unrelated sets of stuff. Right now, it is possible to merge unrelated trees, which is something you almost never want to do.

Nevertheless, Mercurial is off to an excellent start.