Mercurial for solo developers

Tue 15 May 2007

I am in the process of adopting a version control system for my personal projects, not just for source code but for writing as well. I have decided against subversion, although it seems to be the way now to distribute code on the internet. I am currently evaluating Mercurial.

Mercurial is a decentralized version control system. It works differently from other version control systems because there is no central repository. Instead, your repository is an independent branch, a peer of all the others, containing a history of the project. Team members maintain multiple, local repositories for each feature they are working on and then selectively shares the changes with other members. This makes it possible to freely define sharing topologies.

The other advantage of Mercurial is that, because the repository is local, you can make commits without access to a central server, that is, when you don’t have an internet connection.

While these are clear advantages for distributed teams, they should also be considered by the lone developer with an internet connection. For the solo developer, the lack of a central repository is an advantage. The project directory you are working in is the repository, and not a checked out version of a “main” repository somewhere else (tellingly in mercurial the command most equivalent to “checkout” is called “clone”). If you are just developing with subversion on a local machine, for instance, you would normally create the main repository in one directory and then check out a working copy to another directory, splitting your current work and previous versions of between two places. This is redundant for the single developer.

As a lone developer, you can still make use of a remote clone of your repository to push changes to as a backup of your local repository. You can also use the remote repository to coordinate your work on multiple computers.

As far as not having an internet connection, this is not a problem for most people unless they are in an airplane or in a cafe that—god forbid!—doesn’t offer WiFi (and I know there are some of you who like to make commits while out hiking the Appalachian trail). When I am developing I am either at home or at work, where I always have an internet connection. The much more likely scenario, where being able to do commits locally is an advantage, is when the server hosting your central repository goes down. I host my svn repositories on my server at TextDrive. When my server is down I cannot commit changes. With Mercurial you can do local, incremental commits. When you are done working you can push them all at once to the remote machine.

If you are already familiar with version control, the Mercurial workflow is a new thing to wrap your head around. If you don’t use version control, then get started! You won’t have any biases about how version control should work, so you might as well try something that is well suited to the individual developer.

embassy opposition