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.
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.