A look at modern DVCSs

I’ve been a user of the Bazaar distributed VCS from Canonical (the company behind Ubuntu Linux) for a while now, at least for my personal projects. When I first chose it, I had already spent some time playing with Darcs for a few small projects. Darcs got its start in 2001 with roots in the GNU Arch project. (Bazaar’s predecessor - also named Bazaar - also has its roots in Arch.) A couple years ago, Darcs seemed to be lagging behind the newer, higher-profile DVCSs that were getting a lot of development attention. I took a look at the current generation of popular DVCS tools, Mercurial, Git, and Bazaar.

Bazaar and Mercurial are quite similar; Bazaar often gets reviews of being slower, though on average I don’t really find this to be the case. I think I dawdled long enough in the Darcs world that most of Bazaar’s speed remedies had been addressed by the time I compared. Bazaar seemed a bit more polished (being supported by Canonical) and seemed to target multiple workflows, which seemed handy for mixed working environments.

Git was the outlier here. I had heard reports of its blazing speeds, but I found the Windows user experience horrible at the time. And sadly, most of my development time is spent on Windows platforms these days. It also seemed a bit cobbled together at the time, being a collection of scripts and commands, instead of a single command, like the p4 or svn commands I was used to.

Choosing a DVCS for the team

Back in October (when I was still working at Flying Lab Software), we had the opportunity to possibly change from our current source control tool, Perforce, to something new. Choosing a VCS for a team has a few more things to consider than choosing one for your personal projects. Artists and game designers weren’t going to be daily users of the system (it was just for code, not assets), but they might have to deal with it occasionally as well.

Learning curve. Mercurial and Bazaar both seem almost as easy to understand as Perforce. Especially for non-programmers, this is pretty important. Git’s staging and in-place branching are actually really cool features, but they’re only for people who really grok source control, IMHO. It’s much easier to train people that committing is a single action, and different directories are different branches, especially when coming from Perforce.

GUI tools. This is definitely one of those “less important for personal projects, more important for team projects” issues. Perforce’s GUI tools were one of its strong points. While Tortoise-style tools are handy, I don’t consider them a complete GUI solution. So on this front, Bazaar’s GUI was my favorite. Git-GUI is a bit minimal, but effective as well.

Speed. This is where there seemed to be the most contention between people’s perceptions of the tools. “Bazaar is much slower than Mercurial.” “Git is blazingly fast.” So I decided to do a little benchmarking. (Keep in mind this was October 2010, so things may have changed since.) I grabbed 100MB worth of Pirates source code, wrote a script to “touch” half the files (by randomly moving lines in the file around) and tried it out with each of the three tools.

Initial size on disk: 98.9MB

Command Seconds
bzr init 2.5087403s
bzr add . 1.0068486s
bzr commit --message "import" 8.8508177s
bzr st 1.2178222s
touched files
bzr st 1.2800246s
bzr commit --message "one" 4.529809s
touched and committed again
Size on Disk: 113MB
bzr branch Bazaar Bazaar2 119.4228816s


Command Seconds
hg init 0.1897491s
hg add . 0.9264119s
hg commit --message "import" 71.2364679 (!)
hg st 0.2171699s
Size on Disk: 119MB
touched files
hg st 1.900506s
hg commit --message "one" 7.9458864s
touched and committed again
Size on Disk: 119MB
hg clone Mercurial Mercurial2 38.7416304s


Command Seconds
git init 0.2001444s
git add . 46.8636753s
git commit -m "import" 10.8147961s
Size on Disk: 121MB
touched files
git diff 6.6801917s
git commit -m "one" 1.4460605s
touched and committed again
Size on Disk: 121MB
git clone git git2 48.557878s


It’s interesting to see here that Bazaar was still a bit slower than Mercurial, with the exception of committing changes. Given that committing is done less frequently than checking status, I think that puts Mercurial slightly in the lead for speed. Git’s times weren’t nearly as impressive as I was expecting, though I’d read that Git is slower on non-POSIX systems, so that might be the reason. You’ll also note that my second git commit didn’t use -a, so that time might have been even higher had I used it correctly. I understood Git’s staging concept less when I ran the benchmarks.


We ended up not actually switching to a DVCS after I ran all these tests, due largely to issues of integration with other tools and other codebases. I think DVCSs are definitely the future (or the now), though - especially for big, long-running service-style games like MMOs where juggling lots of branches is important.

©2011-2020 Justin C. Miller.   What a horrible night to have a curse.