Posted on 6 Comments

Revision Control Systems

Revision control is of course very important in software development, particularly when many developers are doing a lot of commits in a very distributed environment – like with MySQL: our developers are based all over the planet, but also travelling, off-line at times, and so on.
So revision control interests us a great deal, and distributed (and off-line) systems in particular.

A few years ago, BitKeeper used to be the only one that pretty much had all this licked.
Some emergent Open Source projects didn’t continue, but the current “contenders” appear to be GIT (started by Linus Torvalds), Mercurial (by Matt Mackall) and Monotone (Graydon Hoare), with Bazaar NG (Martin Pool, Canonical) also showing potential.

BazaarNG is written in Python, and Mercurial is mostly Python with a little bit of C. I haven’t tried either yet myself as my previous laptop installation had a Python that was too old. For Mercurial, using Python appears to have eased code contributions by more people (even from non-Python programmers).

I’ve played a bit with Monotone (C++) and talked with some of the developers. The user-interface needs work as it could be simpler (shorter command lines), and I’m getting the feeling the system might be a bit over-engineered: each piece of information is cryptographically signed, individually. There are reasons for this, but signing all information belonging with an object (like a delta) might have sufficed. GIT and Mercurial also sign, but much less. Using some extra logic, they can still derive integrity.

Yesterday at LCA 2006 there was a tutorial about GIT/Cogito by Martin Langhoff (Catalyst IT – and he wrote Cogito, which is a tool on top of GIT). Interesting, as GIT has developed quite a bit over the last half year.
Linus was also there, which was very useful for additional perspective into the background of how GIT works and why, and how it relates to the functionality of for instance BitKeeper.
Of course, it’s very much geared to the way Linus works, but it is very tweakable and an increasing number of other people are also using it for their stuff.

Later, I talked with Theodore T’so who has also used BK and now Mercurial, which led me to meet Matt Mackall (whom, as I mentioned above, is Mercurial’s principal author).
Yes, “everybody” is here! 😉
I’ll definitely be trying Mercurial with a personal project. It has some novel ways of storing history, somewhere mid-way SCCS/BK and CVS and actually manages to steer cleer of performance degradation that usually occurs with longer history. It also has a very simple and easy command set, and work is being done on IDE integration.

I’ve talked with Martin Pool before, but haven’t yet had the chance to try Bazaar-NG.

I’m just very interested in this topic, stemming from my old programming background. This type of tool needs to deal with really important software development workflow issues. It’s good to see so much development and innovation going on in this arena – it has been too dormant for a long time.

Posted on 6 Comments

6 thoughts on “Revision Control Systems

  1. Yes, this kind of tools are definitely very important, though I still didn’t see any major differencies from the way CVS works. Or, better to say, any differencies that would make me to forget CVS in favour of one of those tools.
    Do they even exist? Did I miss them?

  2. If you’re curious about distributed (and off-line) revision control systems, you should consider putting SVK on your “contenders” list above. It can even mirror remote Subversion, Perforce, and CVS repositories to perform offline operations and is written in Perl.

  3. The new developments all deal with multi-file changesets, i.e. commits are atomic across multiple files. A change is not a single file, but a set of files. This is really fundamental and important.

    Also, true distributed version control deals with off-line development. There is no single central repository. You should be able to commit without connecting, and synchronise later. This makes for longer-running branches (requiring better branch/merge handling and decent management of the resulting graph structures), and developers making more frequent small commits as they are working, rather than doing huge commits. From a development workflow perspective, this has major advantages for developers.
    Mercurial can collaps such a set of changesets so that a code reviewer can look at it as a single patch, which of course is good for the overview.

    All this is so far beyond CVS, it’s not even in the same ballpark.
    CVS has no clue about any of the above.
    But, it all depends on your needs!

  4. Sorry, personally I just don’t like it.
    SVN has architectural issues – it has not resolved some CVS problems that the other systems have dealt with. SVK is tacked on top of SVN, dealing with the distributed thing. It kinda works but it’s not nice, and still doesn’t solve any of the other stuff.
    SVN was an opportunity to fix many fundamentals – people indeed don’t like to shift systems very often. I think this opportunity was largely wasted. It’s very unfortunate.

  5. Hi Arjen! This is martin langhoff here — I only talked about Cogito, I definitely didn’t write it. Cogito is the work of “Pasky” Baudis, my own work in the Cogito/GIT space has mainly been on the Arch importer and patches to the cvs importer.

  6. hay!!
    good project 🙂
    senks 🙂

Comments are closed.