Thoughts on Systems

Emil Sit

Jan 23, 2007 - 3 minute read - Research mercurial programming tools

Choosing Mercurial for Chord

Over the past few years, distributed version control systems have flourished; there are now so many that is hard to choose between them. Each choice offers an evolution beyond CVS including, among other things, whole-tree views with atomic commits, complete and transparent offline operation, and excellent branching support. Always on the look out for better tools, I have played with many of these systems over the past few years and watched them evolve. Last month, I chose one: I migrated the source for Chord, my research project, from CVS to Mercurial.

Why Mercurial and not other distributed version control tools like darcs, git, and Arch (tla/bzr)? Since these tools all have similar features, the distinguishing factors for me were Mercurial’s ease of use, performance, and modular design. This means to me that it won’t be hard for me or others to use and it is likely to cleanly develop additional functionality as it matures.

First, Mercurial is easy to use. The interface (e.g., hg ci) is readily accessible to long-time CVS users. You don’t have to learn new names for familiar commands (e.g., darcs record). There aren’t any arcane incantations or odd naming conventions required to keep the repository compact and manageable. Offline access is completely transparent and quite convenient for working at airports or cafes without free wireless. In addition, it is easy to set up both anonymous read-only access (via HTTP using the supplied hgweb CGI scripts) and shared read-write access (via ssh). Not that other systems haven’t improved over the years (e.g., the Bazaar version of Arch), but Mercurial makes a very favorable first impression for usability.

Usability is enhanced by the fact that Mercurial is not slow; it’s actually pretty fast. It doesn’t really matter whether or not it is the fastest; Mercurial is fast enough while being quite space efficient. Choice of repository format has a big impact on this and Mercurial’s authors have clearly thought about how to achieve functionality along with performance: Mercurial’s design (PDF) is laid out in a paper that explains why and how it achieves scalability and performance.

Finally, Mercurial’s design includes an API for extension modules. A modular design (with documentation) means that innovation can be cleanly added on by external developers. There are already a nice set of extensions that provide features like GPG-signing commits, managing patch queues, and cherry-picking commits from one repository and moving them to another. A commonly requested feature is to be able to check-out only portions of repositories: the forest extension is one approach to doing so.

Overall, I am quite pleased with Mercurial and have recommended it to several people. In my next post, I’ll talk about how I managed the conversion from CVS and some early experiences with using Mercurial in my research group.