In the first part of this article series, I presented some history concerning the development of distributed revision control systems, and took a closer look at both SVK and monotone. In this sequel, we will take a closer look at the remaining four systems promised to be reviewed, namely darcs, Bazaar, Git, and Mercurial. The latter three are quite popular, being used by Ubuntu (Bazaar), the Linux kernel (Git), and the Mozilla project (Mercurial).

Synopsis:

• darcs: nice & clean... but scales badly
• Bazaar: Jack of All Trades
• Git: The Speed King
• Mercurial: The Rival
• Conclusions and Outlook

darcs: nice & clean... but scales badly

The darcs system was developed by David Roundy (“David's advanced revision control system”). The software provides a completely distributed version control system and exists since early 2003. In contrast to e.g., SVK, darcs does not know the concept of a central repository, marking it as a truly distributed system. Every repository is potentially equal, and becomes special only if the developers choose it to be. Another feature which is quite different from older systems like CVS, Subversion and GNU arch is that darcs does not separate the “repository” and the “checkout directory.” Revision information is stored alongside the working files, essentially creating a directory that is able to remember (and go back to) older states.

Unlike other systems, darcs has no direct notion of a “branch.” Branching is done by copying the repository to a different place. On filesystems that support linking, the copy shares quite a bit of data with the original, making this task relatively fast and efficient. The operation of darcs is based upon the concept of a “patch algebra”: any state of the directory is modelled as the consecutive appplication of a sequence of “patches” to the initial state. Patches can be changed, and can even be removed. Since there are no branches inside one repository, recording changes is pretty straight forward. Merging is simply copying patch information between repositories. Conflicts that cannot be resolved automatically are marked for manual resolution. All in all, the system is quite impressive in its elegance and simplicity. Of course, you have to adapt your work flow to the way darcs works, not the other way round.

For small repositories, darcs works quite fast, and its feature set is sufficient. It tracks directories as well as files, and its rename tracking works rather well. Of course it is always possible to produce merge conflicts with file renames, but the usual “harmless” standard cases I tested (e.g., developer 1 changes the file's content, developer 2 changes its name) worked without a hitch. This trick alone is something that the average Subversion user is not quite used to, as renaming in SVN still is an invitation to disaster. The unique design of darcs actually allows for some neat tricks, as you can create patch sets as unions or intersections of other patch sets. Tagging is also very flexible, as a tag is just a “virtual patch” that depends on an arbitrary set of patches.

Darcs works well on different platforms, and prepared versions for MacOS, Windows, and Unix systems exist. However, synchronizing between repositories takes a surprisingly long time on all systems, depending on your repository and memory size. Darcs simply appears not to scale too well with project size, as there are reports of memory usage up to 1GB for large trees (i.e., putting the current Linux tree under darcs control would probably not be a good idea). I have personally seen memory footprints of up to 400MB when checking in a 50MB binary file, although it seems to have gotten a bit better with darcs 2.2. All things considered, darcs should be fine for small and medium-sized projects as long as you do not put large binaries under darcs control, and as long as you can live with its strict “a branch is a repository is a branch” philosophy.

Another drawback is the complete lack of alternative user interfaces. There is no GUI, no TortoiseSVN-like Explorer integration on Windows and no Eclipse support either, as far as I know. On the other hand, the darcs commands are quite easy to understand and the tool is actually pretty nice once you are used to it. Since it is so radically different from CVS and SVN it does not even try to emulate their behaviour, resulting in a more or less completely orthogonal command set. Whether this is a good or a bad thing is largely a matter of personal taste. Remains the fact that darcs is a nice and clean system, and has its small but devoted user base not without reason.

Bazaar: Jack of All Trades

Bazaar is the revision control system used by the Ubuntu project. Its development started in 2005 and is coordinated by Canonical, the company by Mark Shuttleworth. The two slogans used by the project to describe itself are “a distributed version control system that Just Works” and “Version Control for Human Beings”. So, it is clear what the Bazaar people are aiming at: a powerful system that can still be used without big headaches. It is implemented in Python, making it very portable and ensuring availability on more or less any platform one could wish for.

The basic tests were passed by Bazaar with flying colors. Checking in a 50 megabyte binary file took just a few seconds, suggesting the hard disk's speed as the actual bottleneck, and rename tracking tests showed no obvious flaws. As in darcs, directories are first-class objects, meaning that the software tracks even empty folders. Repositories can be created in two flavors: the “standalone” version works just like in darcs, making it very easy to put an existing directory under Bazaar's control. Shared repositories have advantages when working with multiple branches that only differ slightly (and thus have much in common).

The normal workflow is similar to darcs and monotone. But where darcs merges branches automatically and monotone pulls changes without the need to merge at all, Bazaar simply refuses to pull changes if branches have diverged. In this case, the only way to pull the changes is through the merge command, essentially emulating darc's behavior. After merging, the merged state has to be committed to the local branch and can then be pushed back, synchronizing both repositories.

Personally, I do not care too much about Bazaar's behavior during merges, as it tends to make merging more tedious (especially when merging over the network). In systems with automatic local branches, you first get all the remote changes, can kill the connection, and then deal with the merge afterwards. However, Bazaar does allow you to commit your own changes into the local branch before you attempt a merge, just as e.g., monotone allows you to do. It should be noted that the global structure of revisions in Bazaar is once again a DAG, although here the local branch is treated as special.

Performance feels quite good, as Bazaar seems to have been improved a lot in that regard lately. Reports by people on the 'Net confirm this, rendering Bazaar a viable solution even for larger projects. Graphical shells are available, too, as well as integration into Eclipse and other IDEs. The Windows version comes bundled with TortoiseBZR, which is yet another variant of TortoiseSVN. However, it seemes that the version bundled with Bazaar 1.6 is still fairly limited in its functionality, meaning that you will have to do some things at the command prompt.

Bazaar can also be extended by plugins, and a large number are already available, ranging from command extensions to notification addons. Particularly interesting is the rebase plugin that essentially enables you to move around sub-branches in the revision graph. This is a powerful feature, allowing you to re-order revisions before pushing them back to the main repository, and adds functionality historically to be found only in Git. All in all Bazaar is an impressive system, and one cannot really go wrong in choosing it. Personally, I found the advertising texts on the web page a bit over the top, but maybe that's just me (the “comparisons” against Mercurial and Git were definitely a bit childish, albeit the response by the Mercurial team was not much better).

Git: The Speed King

As mentioned before, Git is the revision control system developed by Linus Torvalds who is (in his own words) “not a source control person.” In fact Torvalds claims that this was essential to the evolution of Git, since he never managed to convince himself that “CVS did something sane.” Of course, several distributed systems already existed at the time Torvalds designed Git and undoubtedly have influenced its design. Apart from the proprietary BitKeeper, the two systems I would like to mention in this context are darcs and monotone. Both had already existed for roughly two years at the time of Git's inception, and both show clear similarities to Git concerning workflow.

The basic operation of Git is nothing new to someone who has used other distributed systems before. It implements the same “the directory is the repository” philosophy we have already seen, making it especially easy to put existing code under the VCS's control. Directories are second-class citizens, as Git does not track them explictly. In general Git does not care much about files either, but (according to its creator) rather about their content. This also means that it is usually quite unimpressed by file renames. Large binary checkins were no problem during my tests. Storage is quite efficient and strongly compressed, often resulting in a repository that is actually smaller in its entirety than the current checkout.

Apart from duplicating the whole repository (like darcs), Git can work with named and unnamed sub-branches in the local repository. After pulling in changes from other repositories, Git will often produce different strands of development each with their respective “heads” in the local repository, just like monotone does. These branches can be very easily merged by anyone who happens to have the respective changesets, and then pushed back. A nice feature is the possibility to have a “local” branch that is not automatically pushed to the other developers, making it easy to test changes without the need to create full-fledged branch repositories.

One aspect that really sets Git apart is its speed. Updates are blazingly fast and the dependence on repository size is very, very weak. For all facts and purposes, Git shows nearly a flat-line behavior when it comes to the dependence of its performance on the number of files and/or revisions in the repository, a feat no other VCS in this review can duplicate (although Mercurial does come quite close). Apart from raw speed, Git also provides some powerful features like “git-rebase”, which allows for efficient management and manipulation of local, temporary branches. However, Bazaar and Mercurial are rapidly gaining ground due to their plugin-based design (and already offer plugins for rebase's functionality, for example).

Git is available as source code for practically any POSIX-like platform (BSD, Linux, MacOS etc.), and most major binary distributions provide packages ready to be used. One drawback at this time is Git's (lacking) support for Microsoft Windows platforms. These are only “officially” supported through Cygwin, although another version (msysgit) provides almost complete functionality in an easy-to-use installer package. Nevertheless, Windows support can still be problematic e.g. if you have to work in a mixed environment. A few years back, msysgit did not exist, leaving Cygwin as the only option and effectively making the Mozilla project reject Git for that very reason. Of course, things have improved greatly with the availability of the native client and I expect further improvements to it.

Mercurial: The Rival

Roughly at the same time Linus Torvalds designed his Git system, kernel hacker Matt Mackall started his own: Mercurial. While Git was a POSIX application very much in the UNIX spirit, consisting of several small tools written in C and shell script, Mackall decided on a different approach for Mercurial. His solution consisted of a monolithic Python application, which used C/C++ only where it absolutely mattered for speed.

The net result of that decision was that Mercurial was available for several platforms (including Windows platforms) from the get-go, and this has not changed. Since it uses optimized compiled code for critical operations, it is very fast. Not quite as fast as Git, but very close and with similar scaling properties. This means that Mercurial handles large repositories and/or large revision histories particularly well, just like Git. Since Mackall is a kernel developer, he designed Mercurial explicitly with that goal in mind, since at the time there was even the possibility that it would end up as the kernel's VCS.

Although the kernel developers settled on Git, the Mercurial project was continued and its interoperability with Git further improved. It is possible to convert repositories between the two systems without much hassle, and even a synchronized, unofficial Mercurial kernel repository exists on the kernel.org site. Like I said before, the two systems are eerily similar in many aspects (for example, Mercurial does not directly track directories, just like Git), although the implementation details differ greatly. However, while Git was very powerful from the very beginning, but lacking a user interface that enabled it to be used by mere mortals, the development of Mercurial happened the other way round. It had a clean and usable interface from the get-go, but a number of advanced features were only added later.

One example for this is the handling of branches. Early versions of Mercurial had no support for named branches, and it was considered best practise to just create a “clone” of the repository. So in this regard, early Mercurial was very much like darcs and monotone. Named branch support was implemented as a later improvement, and “temporary” branches (i.e. local to the repository) only recently. In fact the Mercurial team long argued that a project's history should be both complete and fixed, and Git's “history-changing” features like local branches or rebase were both unnecessary and dangerous.

Actually, both positions are correct in their own way, and one can work perfectly without features like git-rebase. It is a matter of personal choice and philosophy, which is why some of the more advanced functions in Mercurial are offered via plugins (e.g., patch management via “Mercurial Queues”). Feature-wise, Mercurial has gotten very powerful indeed in recent releases, mirroring and sometimes even surpassing Git's functionality while remaining its closest rival in terms of performance. Since its main part is implemented as a Python API, it is quite easy to extend Mercurial's functionality via custom plugins.

Conclusions and Outlook

After looking at all the contestants, it is really difficult to nominate a “winner.” Four systems of the six are definitely viable choices for most purposes and the choice is largely a matter of personal taste, leaving SVK and darcs as the only contestants I cannot recommend for general use. SVK has so many serious flaws I do not have the room to enumerate them all; to name the worst: it is based on Subversion (inheriting many of its limitations), it is horrendously slow, it hogs quite a lot of space on the hard disk and the setup process is apparently optimised for people who actually like pain. Add to that its unflexible, centralised workflow and the fact that it has been written in Perl by essentially a single person, resulting both in slow development and an “unfirm” future.

darcs, on the other hand, feels indeed very nice and clean, and it should actually work quite well for small projects. However, it is not very flexible, also tends to hog disk space, and quickly gets pretty slow when your project grows. Although I hate to have to say it, it is simply not worth the effort, considering that the alternatives offer at least comparable performance for small projects, can be used in a way that very closely mirrors darcs' workflow (but are more flexible), and scale much better. The patch algebra idea is intriguing, but that's it, more or less.

There is no truly “bad choice” among the other four systems, since they are all actively developed and used by prominent open source projects. Monotone adds an additional layer of security that some people will find attractive. Bazaar allows both central and standalone, workspace-integrated repositories and also offers many interesting plugins, although I find the developers' “we are the best” attitude a bit annoying. Mercurial and Git are the speed kings, and are also feature-rich and flexible.

If you really want a direct recommendation, it would be thus: download Git and Mercurial, then throw dice. Personally I like the “it just works” approach of Mercurial a bit better, and the fact that it is written in Python. Also for cross-platform projects needing Windows support Mercurial is (at this moment) probably a tiny bit less problematic. If you work in a completely UNIX-centered environment, Git might be the slightly better choice. However, both systems work very well, are stable and very, very fast. So it's a tie, more or less.

In the third (and last) part of this article series, I will try to confirm the impressions I got so far about performance. So expect lots of boring numbers, but maybe a few pretty graphs as well. Stay tuned!