So, I think most of the open source world has agreed that the DRCS model fits our working style better than the traditional model pushed by SVN and CVS etc. And in this DRCS world we have rallied around 3 main tools: Bzr, hg, and git. And in an even greater display of complacency we have given those 3 tools quick and general classifications that became obsolete almost a year ago. Bzr is user friendly but slow and technologically inferior, hg is the champion of the middle but with slow development and a lackluster community, git is wicked fast and ‘The Right Way’TM but a pain to use.
Really? Come on guys, those molds were cast almost a year and a half ago, isn’t it time we looked at things again? Git has an entirely new interface, hg has a slew of plugins/extensions, and bzr has a completely new repo format, and network protocol, resulting in a massive speedup. Now I’m not claiming to be some unbiased source, and comparing 3 incredibly robust tools is not my job, but given the amount of support that Git receives from its very vocal supporters makes me feel a need to give props to my favorite DRCS system: Bazaar.
That’s right, Bazaar (or bzr) is awesome. Sure, git is awesome too, and so is mercurial, but I have found myself loving bzr. I’m not going to attack other DRCS tools, I just want to extol the awesomeness that is bzr.
1) Bzr is Python-Tastic! – As a python hacker, being able to utilize a robust API and plugin system is a cool plus, this also generates lots of powerful and complete plugins, which leads me to the next point.
2) Bzr has a ton of plugins! – Plugins like bzr-avahi (allows the discovery of branches on a local network, great for sprints/hackfests), bzr-svn (makes working with upstream repositories easy as pie!), quilt and gtk tools.
3) Bzr works on Windows – Yeah, I’m not a huge fan of accommodating Windows users, but it makes collaboration easier, I don’t have to make my roommate boot into Ubuntu to lend a hand with some CSS bugs.
4) Bzr is easy to share – The ability to push branches to some central repo is a big component of distributed development. While patches work in some cases, most of the time, having access to a branch makes the whole system work better. Both Git and Hg require a bit of work to set up a new repo and push a branch, bzr supports a ton of protocols and can create the target directory/repo with one command. Sharing is easy!
5) Bzr is fast – Maybe others are faster, maybe it could be a million times faster, I dunno. What I do know is the only thing I seem to wait on is my net connection… I realize that many people need more than that. So here you go. http://bazaar-vcs.org/Benchmarks
6) Bzr is small – In my development model (a shared repo with branches inside of it) bzr is compact and aware of disk space, without repositories it might be huge, I dunno.
7) Bzr is clear about whats happening – I can follow what Bzr is trying to do with my code. A branch is a new directory, and I can always see my code. Not only is this comforting/reassuring, but I often utilize IDE’s like Wing, Eclipse, or Monodevelop when working on code, and while they can handle other systems, directories for branches translates to every editor and works well. 
Bzr is reliable – A massive suite of unit-tests and a commitment to their excellence offers some comfort that I won’t be left holding half of my code in one hand and an ugly binary blob in the other.
9) Most of all, its a feeling. Its hard to explain, but I don’t notice bzr. Its just there, and I just have my code. I rarely take notice of it, and don’t focus on it. I spend 99% of my time coding and every 30 min I enter a terminal for a few seconds to do all my DRCS stuff. Maybe its why people who use Bzr aren’t very vocal about it. Its not a revolution in revision control, and I don’t do a million cool things in it. I just write code, and bzr is there, doing whatever it does.
All I can say is thank you for summarizing why we love bzr
Couldn’t have said it better myself. Bzr is so easy to use I almost forget about it being there and that’s a good piece of software in my book.
Bzr is still the slowest of the three. Git is the fastest and Hg is in the middle. Here’s a recent benchmark using the Linux source tree:
http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg-performance-on-the-linux-tree/
Robin: I wouldn’t argue that bzr is faster than any of the other options, I’m just noting that I never wait on it, which is fast enough for me.
[...] Kevin! I am a very vocal bzr user too!! [...]
Vocal git users are why I don’t try git, much like Macs and other things here in life. I know it’s a stupid reason, but I don’t want to be associated with annoying loudmouth “envangelists” (zealots), so I stay away. It doesn’t matter how nice it is, then. Actually, Python users fits a lot into that folder as well. Just shut up and have, will you, all of you?
That said, bzr feels very “human” and I like that. Very few people have benchmark-critical needs, but a lot of people apparently have benchmark-bragging needs. Whatever…
Thanks for the post, very level-headed. I’m just getting into bzr…very reassuring how invisible it is to you.
What’s fun with DVCS arguments is that it’s pretty much always applicable to all the opponents. It’s just the explanation that differs a bit.
Let’s have a try with git (nothing personal, but I like the exercise).
1) Git is script-tastic! – As a day to day bash user, it is very easy to script tasks and such with the low level plumbing git offers me. And better: it’s just the same using perl or python or even ruby!
Git is reliable – A massive suite of unit-tests, and there is always a way to recover from a mistake (reflog, etc.). Being able to undo is always better than a warning, isn’t it?
2) Git has a ton of porcelains (equivalent to plugins). git-svn is probably the most successful dvcs-svn bridge out there, and gitk, git-bugzilla and others are just rocking.
3) Git works on Windows. Yeah, HG and Bzr do too
4) Git is easy to share. Not only you can push your changes to some central repo (using git’s protocol or ssh or http or rsync or whatever), but you can also easily send them by e-mail or to your bugzilla with a single command!
5) Git is the fastest out there, even for big projects. Every command that takes 30s on the linux kernel is too slow according to its developpers. Isn’t that a good benchmark?
6) Git is small. Gedit’s repository, containing all its history, is less than a half of a single svn checkout.
7) Git is simple, predictible. It stores everything in a single directory with very simple file formats, stable over time, and well described: I don’t need git to take my data out of an old tree if I don’t have it (yeah, it’s pretty important to me since one day git might disappear).
9) Most of all, its a feeling. I especially like the way it stays out of the way. You can code as much as you want, and then switch in “VCS” mode and commit your changes, the way you want. git-add –patch is a must for that: it allows you to choose which hunks of your diff you want to commit, one by one. This way I can just write code, and git is there, doing whatever it should do, nothing more, nothing less.
Do someone want to do the same for hg now ?
@nud
Sorry, but git does *not* work in Windows, at least not seamlessly. If I need to run a separate shell just to get my revision control running, that’s not exactly seamless.
I do hope that that’s getting addressed by the ‘Summer of Code’ git projects, though. In the meantime, I’m back to evaluating bazaar again – neither hg nor git can be coerced to work with tailor under windows without major effort.
Robin, Nud: Git is only faster if you don’t count the time it takes to GC and repack – tasks that the other tools do automatically. Once you factor those in it is substantially slower.
[...] http://kubasik.net/blog/2008/05/19/bazaar-and-its-rockage/ http://www.grillbar.org/wordpress/?p=271 [...]
Avdi: but you can gc or repack when you don’t need to wait for git to finish, which is not the case with checkout/diff/commit
Anyway, my point was just to show that, whatever DVCS you prefer, you can pretty much take the same arguments and put them forward, subjectivity helping…
Bzr is fantastic, but bzr-svn still sucks. It requires patches to svn, and it’s not really a two-way integration. Even in Windows, for now, Git-SVN is the only decent choice if you need SVN integration.
I ? bzr too!
is there a package for bzr-avahi for ubuntu ?
Problem with bzr is the lack of good online repository browser… Launchpad uses Loggerhead, which sucks :/ There are not much alternatives for bugs-system management either… Launchpad is the only way to go
1) Bzr is Python-Tastic? Well, what happens if I don’t like Python? Which I don’t.
The rest of the points also apply to git, except “Bzr works on Windows”, but there is work towards that, and given how much git facilitates development I bet in no time we will have a tortoise-git or something.
I’ll have to learn bazaar anyway, but the fact that it’s developed in Python is a big drawback to me.
Git FTW!
I tried bazaar a few times, but it still is really slow.
Any bazaar operation, even something like “bzr status” in a directory without a repository takes at least 200ms before finishing. That’s just enough time to have to wait until text is displayed on the screen, which can be really irritating.
I tried to do a few benchmarks on large bazaar repositories, but couldn’t find any well-known projects on the http://bazaar-vcs.org/WhoUsesBzr page. That’s why I tried the recently posted gtk+ import.
Even doing something simple as displaying the last log message (bzr log -l1) takes multiple seconds to run. Doing a “bzr log -l1 Makefile.am” takes 17(!!) seconds to display the last revision touching the makefile!
The same is true for the smaller gedit repository — 1.2 seconds to display last log message, 3.8 seconds to display last change for Makefile.am. And that’s with just 5000 commits! (That’s with the recently released bazaar 1.5)
It seems that bazaar just doesn’t scale at all. With those kind of results, it would be a mistake to choose bazaar for your project if you think it might get more than a few commits, or you’ll be waiting for every bzr operation you do.
João Marcus: The dependencies for bzr-svn are certainly one of its disadvantages if you’re not on Debian or Ubuntu. But how is bzr-svn not two way integration? It allows you to push/pull from Subversion branches just like you would with any “regular” bzr branch.