jump to navigation

Wanted: Rock Solid Version Control July 11, 2007

Posted by Ian Clatworthy in Bazaar, Collaboration.

In earlier posts, I outlined the top 6 criteria that teams ought to consider when investigating and selecting a VCS tool: reliability, adaptability, usability, extensibility, integration and low administration. I’ve just announced the availability of Bazaar 0.18 Release Candidate 1 so now seems a great time to discuss my most important criteria – reliability.

In terms of impact on team success, tools are pretty low in the pecking order of things when compared to clear leadership, motivated people and just right processes. However, the new breed of version control tools are exciting precisely because they change the software development game: they enable new ways of communicating and that in turn enables new ways of thinking about software development. But outside the AlphaGeeks, Distributed Version Control will only reach criteria mass as a technology across the open source world and in commercial software development shops if we can show the technology is ultra-reliable. To me, that means 3 things: Design for Reliability, extensive test suites and strong auditing, e.g. cryptographic signing of commits.

Design for Reliability is all about taking a conservative approach – valuing correctness above other things. As a young software engineer back in the early 90s, 10s of thousands of people woke up to cold showers in Sydney one morning because of a corner-case bug in my code controlling the off peak hot water system. That sort of event tends to have a life long impact on how one designs software! I found it really interesting watching Linus talking about Git’s design and how someone trying to corrupt the Linux code archives had a similar impact on how he designed Git. I really like how Linus made reliability such an important design consideration for Git yet it hardly got a mention in the almost 400 slashdot comments on the video. ūüė¶ By offending so many central VCS users by assuming that what’s best for him must be best for everyone else – a point I’ve addressed elsewhere, I fear a really important point of his has got lost in the follow-up noise.

As a member of the Bazaar community, I want to see the various DVCS communities working together and learning off each other so we can collectively move the IT industry to a better place. While it might generate more press, I really want to minimize my criticism of other DVCS tools, particularly Mercurial which is my preferred tool after Bazaar. But I do feel it is important to mention that some operations in Bazaar may never be as fast as they are in Mercurial because of reliability-driven design decisions we’ve explicitly made. For example, Mercurial uses hard links when branching locally making that operation pretty damn quick. In contrast, Bazaar not only copies content because of our concerns with hard links but cleans up any junk in the archives as it goes. When you branch in Bazaar, you know your new branch is as clean as clean can be. If you don’t care about that, no problem – a simple cp -a will get you a new branch real quick instead (without the integrity checks). Robert has reported other areas where Bazaar is deliberately more conservative in the name of correctness. Bazaar undoubtedly has its own reliability quirks I’m not yet aware of. If you like another DVCS tool because it’s more reliable than Bazaar, please speak up so the Bazaar team can do something about it! Like I said, I think it is very important the various DVCS communities learn from each other and Design for Reliability is something all of us need to be putting at the top of our lists and actively addressing.

An extensive test suite ought to be a mandatory feature of every serious VCS tool released these days. VCS tools need to be reliable across umpteen different operating systems and every one of those has umpteen different versions. In a world where security updates for all major operating systems are released at a high frequency, exactly what an ‘operating system version’ means can be very nebulous indeed. If you’ve never had an application mysteriously break after a Windows hot-fix, my guess is that you’re in the minority. The same thing will happen on OS X and every major Linux distro at some point – it’s just a matter of time. The only safety net you have for verifying that such an important tool is working correctly in your particular environment is an extensive test suite. Bazaar’s reliability and robustness is no accident: its built-in regression test suite for 0.18 currently has over 7000 tests!

While reliable technologies and algorithms are critical for ensuring repository robustness, completely trusting the integrity of a VCS repository is a far larger topic as explained by David Wheeler. Cryptographic signing of commits really matters when it matters. All the leading distributed VCS tools have this while many of the central VCS tools don’t. In 5 years time, I suspect this feature will be available in all the popular central VCS tools as well, partly driven by the Sarbanes-Oxley craze/disease sweeping the US. (Those Enron guys have a lot to answer for.) In the meantime, this is another great example of how DVCS technology is leading the way.

As I mentioned earlier, Bazaar 0.18rc1 is now available. Please help us test it by downloading it and giving it a go. Just right processes are an important part of delivering reliable software and there is no better time than now to tell us what you think and how we can make it better!



1. Matthieu Moy - July 11, 2007

Just one detail about “cp -a” : that’s not really recommended anymore (it used to), you should really be using shared repositories instead.

If you hardlink, all the append operations will append to both branches, so, you’ll end-up with a branch containing stuff that talk about the other, and you don’t have appropriate locking, so concurrent accesses to both branches can indeed corrupt your branches (precisely the kind of things we’re talking about here ūüėČ ).

2. brendan - July 12, 2007

By the way, Mercurial’s clone –pull operation branches in the same way that you describe bzr branch.

3. James - July 12, 2007

Monotone has similar sanity checking – in some cases a little too much which gives it its reputation for slowness. See also http://community.livejournal.com/evan_tech/216906.html which discusses how the backup restore path is the same code path normally used.

4. Sistema de Controle de vers√£o distribu√≠do: Bazaar « Beyond Click - November 1, 2007

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: