However, it does meet the most important criteria: It just works for me.

Now for the big disclaimer: Most of the projects I use bzr to manage fall into 1 of 2 categories:

1. Projects with small teams (1-4 developers)
2. Public projects where I just want to grab the source and maybe maintain some local patches

If I needed to somehow manage a project with dozens or hundreds of contributors (like Gnome or the Linux Kernel), git would probably look a lot more appealing to me. After all, it was designed for large code bases with lots of contributors and branches.

I’ve seen lots of git cookbooks popping up lately, so I thought I’d explain my bzr workflow for the 2 use cases I list above.

1. Starting and sharing a project with a small team
Prerequisite: You’ve created a directory with some code in it.

1. Turn your source code directory into a bzr repository:

   ~/src/foo$ bzr init

2. Add you source files:

   ~/src/foo$ bzr add

3. Commit:

   ~/src/foo$ bzr ci

4. Push my changes to a remote location* other team members can access:

   ~/src/foo$ bzr push --remember sftp://some/file/server

Done! My favorite part is that besides the --remember option, bzr just does what you expect without any flags or configuring. The --remember option simply tells bzr to use that location for future push commands (so you can drop all the typing after “push”).

For more information check out the excellent bazaar documentation on sharing code.

2. Getting the code for an open source project

Unfortunately most big bzr-hosted projects are on Launchpad which makes for a pretty boring demonstration:

~/src$ bzr branch lp:terminator # yawn

To make matters worse, non-Launchpad hosted projects are nearly as dull:

~/src$ bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk

In each case bzr will create a new directory for you using the last part of the source path (terminator & trunk respectively). You can optionally give it a second argument to put the branch in a different location. The destination can even be a remote server!

~/src$ bzr branch http://source/branch sftp://destination/branch

Ok now I’m just showing off. I’ve never found a use for that feature. However, I do appreciate that a location is a location to bzr regardless of whether that location is the local filesystem or a remote server. It just works how you’d expect it.

Chapters 4-6 of Bazaar’s documentation give some excellent examples of various collaboration workflows.

Bonus Feature: Subversion mode!

So its not really Subversion mode, but bzr does support pulling repositories via the checkout command and updating your working copy from the remote repository via the update command just like Subversion. As you would expect, the commit now sends changes directly to the remote server.

While I’ve used this feature mainly to make transitioning to bzr easier for Subversion users, Bazaar’s documentation has some excellent techniques for making advanced workflows easier using checkouts.

• bzr+ssh is faster than plain old sftp but requires bzr to be installed on the server.
• Setup ssh connection multiplexing using ControlMaster in ~/.ssh/config and leave an ssh session active to speed up bzr operations.

Gnomers have been discussing DVCSes a lot lately, and at least one seems to prefer bzr as the repository format and git as the protocol it speaks. If this sounds like madness to you, you’re not alone.

What I don’t understand is why more people don’t choose to keep Subversion as their repository and just use the $DVCS-svn of your choice?

Granted I’ve only used bzr-svn a bit, but it worked quite well and seems to only be getting better. I hear git-svn is quite good as well (but iirc hg lags behind the competition).

The benefits of this seem pretty nice:

• Repository and Project management tools could get by with only first class Subversion support.
• Directing inexperienced users to download code would be standardized.
• Linux distributions wouldn’t have to ship 5 different VCSes (cvs, svn, git, bzr, hg), although the VCSes don’t take up much space.
• Developers could use whichever tool they preferred, publish branches to any one of the zillions of free hosts for their DVCS of choice, and get on with their life.

Answering my own question…

The obvious counter argument is that in order to share code you either:

• …force everyone who cares to use your DVCS.
• …or lose some of the benefits of your chosen DVCS and share code via a SVN branch.

Lets face it, both options are a pretty big hassle for developers. Comprises always are.

For smaller single projects the overhead associated with going this route probably isn’t worth it. You’ll probably either end up losing 75% of what makes a DVCS handy or just use SVN.

Why is Gnome not considering this option though?

This option seems ideal for projects like Gnome. Individual modules will probably adopt a preferred DVCS, and thats fine. None of them are so different that a competent developer couldn’t yank some revisions from an unfamiliar DVCS.

The project as a whole (and individual modules) would continue to remain uniformly easily available through a single svn checkout.

At the very least isn’t this better (at least saner) than bolting git onto bzr’s repository format?

Audience Participation

I’m not a Gnome developer though. Just a curious user. However, as a fellow developer I am left wondering: why isn’t this a good option? Are $DVCS-svn connectors just not good enough? Are the comprises too great? Or the most likely: am I just missing some obvious showstopper?

Update 2: Retracted the meaningless Google Trends point. Thanks to commenters for pointing out how meaningless it was. I still feel like git has a much stronger web presence than bzr or hg, but its just another one of the many “gut feelings” in this post.

The DVCS wars have been raging for a while now, and in case you haven’t been keeping score, git is winning. Admittedly I have no proof and don’t even know if proof is possible, but I have some good evidence of git’s march toward VCS dominance:

• Git dominates every other DVCS by an order of magnitude among Debian packages (that link to their upstream repository).
• A recent survey of Gnome developers found an overwhelming support for Git over other VCSes.
• Git dominates Google trends. Speaking of Google, they have 4 Tech Talks on Git, and absolutely none for bzr or hg. Update: hg has one – see comments.
• Why Git is Better than X – More than the site, the lack of popular counter-argument sites springing up leads me to believe hg and bzr don’t have nearly as fanatical of supporters.

Also note some of the major upstream projects using each DVCS:

Communities

Git seems to be attracting the most diverse communities as well:

Git: Linux Kernel, X.org/FreeDesktop, Ruby on Rails
Bazaar: Ubuntu, Ubuntu, Ubuntu
Mercurial: Pythonistas, projects that need better Windows support than Git offers

Once again I don’t really have any stats to back up these assertions, they’re just my biased observations.

Personally…

I tried learning Git soon after it was first released and failed like so many others. Unlike many of those others, I never went back to give it another shot.

Next I learned Bazaar and felt comfortable in it almost immediately. Now I use Bazaar as my preferred VCS and quite like it mainly because it works well and was very easy to learn. I know its not the fastest, but its so far from being a bottleneck in my development process I don’t notice.

I learned Mercurial for work and use it at least as much as Bazaar, but I’m not sure why anyone would use it over Bazaar. I think people who learned Mercurial first think the same thing about Bazaar.

And perhaps thats part of why Git is winning. It seems fundamentally different from the other two which is probably why its the only 1 of the 3 I haven’t learned.

THE FUTURE!!!!!!!11

I actually don’t plan on learning git any time soon. My time for playing with new technology is currently taken up testing nginx, spawning, and FastCGI.

I suspect thats the norm as well: people who already know a DVCS probably aren’t looking to migrate between them. The few that are, are probably moving to Git.

I think we’ll see the current trend of Git’s lead widening over bzr and hg as well.

However, I don’t see the war ending anytime soon. The fact of the matter is all 3 of them are great and the weaker DVCSes have already fallen prey to evolutionary forces (monotone, darcs, etc).

Flamebait

What are your thoughts on my completely contrived DVCS War? Which do you prefer? How many do you use? Are my assumptions about popularity (in particular the various communities around each) accurate?

I wish Ohloh or cia.vc gave VCS usage statistics, although I’m not even sure they record that data.

Thanks to jQuery and the jQuery History plugin, searching is now done via AJAX but it doesn’t break your back and forward buttons.

The navigation callback in JavaScript ought to be more of a proper state machine, but considering there are only 3 states (blank, about, and searching) I’m not too concerned.

Grouped Searches
I played around with hzzah a bit more after I noticed its search results were far worse than those on Yahoo.com

It seems Yahoo.com only returns 1 or 2 hits per domain, whereas the BOSS API will happily return hundreds all from the same site.

This means if you’re vain like me and search for your name, you get pages of links to your blog and nowhere else. The Yahoo.com results are pretty good and only return 2 hits for my blog.

So I grouped hits by domain name, but since I broke pagination in the process, searching for myself is completely worthless now.

I have some ideas on how to fix that, but they’ll have to wait for another time.

Version Numbers

Squint at the bottom of the page to see the current revision number.

Anybody know how to have that increment automatically when I do bzr up on my server? I haven’t looked for a post-update hook which would do the trick.

Update: Sorry about the tacky donate link all. I tried to hide it from feed readers with WordPress’s <!–more> feature, but evidently that doesn’t apply to feeds.

When it comes to market share, Google is to Searching as Microsoft is to Operating Systems. Thankfully Google has won their dominant position by creating a really amazing product (you can find plenty of discussions on why Microsoft is on top elsewhere).

Recently Yahoo! opened up their search APIs for anyone to use along with a handy Python library. In a time when Yahoo’s very existence is being threatened, I felt a pang of nostalgia for the search engine that fed me decent results for “free dos games” throughout the mid-90s.

So last night I whipped up a little search engine called Hzzah!*

Features:

• Simple
• No ads, cookies, or even JavaScript (at the moment at least)
• Open Source! BSD to be precise.
• Did I mention simple? That’s really all it has going for it…

If you have Bazaar installed you can grab the code a variety of ways:

# If you know Subversion, use this method.  `bzr up` will keep you up to date
bzr checkout http://michael.susens-schurter.com/code/hzzah-public
 
# If you want to hack on Hzzah or are comfortable with bzr, feel free to branch
bzr branch http://michael.susens-schurter.com/code/hzzah-public hzzah-steve

You can also grab a zip, but its probably going to become out of date quickly.

Read the README file for help setting it up.

And like I say in the README, if you’re feeling generous, feel free to toss some cash this way:

* Make fun of the name all you like… there’s no good domain names left. The name is inspired by a friend from college for whom huzzah was her exclamation of choice.

svn up

…to update my code.

Today I ran…

svn switch http://svn.automattic.com/wordpress/branches/2.3

…followed by visiting the upgrade script page and everything worked beautifully!

Anyone not using subversion to update WordPress is doing way too much work! Time to play with tags…

Now if I was really cool I’d use bzr to maintain my local code changes and plugins in my own repository… maybe later.