Congratulations to the Bazaar team, who just released version 0.12 of my favourite free software distributed revision control system. Well done Martin, John, Robert, Aaron & co.

The big focus as they move to 1.0 is performance, and a key part of that is the performance of revision control across networks. Since the whole point of internet-based collaboration is to share code and innovation between developers in different parts of the world, network performance is a key issue for the team.

Bazaar has the neat property that you can publish your branches using only a web server, with no special features. Just exposing the files as a read-only tree over HTTP is enough to publish your branches. That’s nice and easy to setup – combined with SFTP support it means that just about anybody with some sort of personal web space can publish code in a format that is easy for other developers to collaborate on – with full revision control for everybody.

The disadvantage of this is that HTTP publishing (or any sort of virtual file system) requires that files be read one-at-a-time, with all the work being done on the client side. That means it’s difficult, or perhaps impossible, to make the whole thing super fast. For that, you need a server which understands “branches and changesets”, so that you can talk to it using a specialised protocol with meaningful questions and answers like “what’s changed in this code since I last came by and asked?”

This latest version of bazaar includes just such a smart server. It’s really easy to setup – if you have an ssh-based account on a machine, you can work with your remote branches very efficiently now – in fact, it’s much faster checking for updates using this smart server than using something like rsync.

This is just the first cut – over time, I think the smart server will become more capable, the conversations more “high-level” and, as a result, the performance even better. Robert Collins has written up a comprehensive page on how to extend and improve the smart server – Python coders with an interest in revision control should check it out. This complements his article on extending bzr itself with plugins. There are a lot of very cool plugins already – Jelmer’s “SVN branching and committing from BZR” plugin really shows how we can bridge the divide between different version control systems with bazaar, which has an underlying model that is a superset of the other major free systems.

6 comments:

  1. David Mackey says: (permalink)
    October 31st, 2006 at 5:34 am

    Why is it that open source products seem to have such a conservative versioning scheme as compared to commercial software?

  2. Jeremy says: (permalink)
    October 31st, 2006 at 6:00 am

    Because the commercial software has big bloated version numbers for marketing purposes. Would you rather use version 0.12 or version 12.0?

  3. lzap says: (permalink)
    October 31st, 2006 at 7:40 am

    Easy answer. The commerical projects has one goal – to achieve the final version in given time and fixed budget. There is usually no time for long testing, dozens of release candidates or refusing undocumented code. The team have to satisfy the boss by satisfying the customer by releasing some version.

    On the other hand open source has different goals – quality, scalability, platform independance. Open source evolves freely and usually do not know terms like customer, budget, invoicing date, vacation, holiday etc. Bigger open source projects are in the middle – good code + good marketing and management. I know one person at least who knows lots about this :-)

  4. Mike Morris says: (permalink)
    October 31st, 2006 at 8:25 am

    Funny, I read that as “Boozer”… :-)

  5. Kirk Bridger says: (permalink)
    October 31st, 2006 at 4:59 pm

    Commercial software versioning is determined by non-developers usually. That’s why the versioning is different in my opinion. Open Source versioning is usually determined by the devs who use a sane, systematic, lgical approach. Once the product actually needs to get sold or marketed to the public, versioning becomes part of the marketing. See Firefox for example. Why is 2.0 different than 1.5?

    Advantages and disadvantages to both approaches – it just depends on who is asking questions about the versions.

  6. Gord Allott says: (permalink)
    November 14th, 2006 at 5:40 am

    thank heavens the whole ‘adding random letters to the software instead of a version number’ trend has gone, xp,? mx? gibberish is what it was