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.

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!

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.

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!
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). 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?
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 ?

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…