Distributed Development with Mercurial in Action

When someone is used to working with CVS, Subversion or other centralized revision control or source code management systems, the distributed SCM systems seem a bit “alien” at first. One of the greatest “myths” about dSCM is that they encourage forking a project, creating multitudes of slightly incompatible branches. This may be true, but it is also true that it is very often necessary to temporarily “fork” from the mainline of a project’s source code, because there is — for example — a minor buglet in one of the most recent changes.

This is exactly what happened to me this morning, with the source code of Mercurial itself. I pulled the latest changes of the “Crew Repository” and found out that one of the regression tests was failing. The precise mechanics of looking for the exact changeset which introduced the bug are interesting, but slightly out of topic for this post, so let’s just say that the “bisect” extension of Mercurial helped a lot.

When I found the changeset that introduced the bug, I fixed it with a local patch, committed my own fix to a local clone of the Crew Repository, and emailed the mercurial-devel mailing list. In the meantime, Brendan Cully was working on an alternative fix, and pushed his own fix to the official Crew Repository. I re-pulled his fix, discussed a bit the differences between his fix and mine through email, and merged the two fixes in my own Mercurial clone repository.

The whole affair happened in less than 15-20 minutes, and it can be seen in the graphical history browser of Mercurial here:

hg view screenshot of bugfix merge

Note how the first bugfix I “pushed” to my own Mercurial workspace (at 2007-06-18 05:52:15) has a timestamp which is earlier than the merge operation on top of which it was pushed. This is ok; it’s a side-effect of fixing the bug elsewhere, and using “hg import” to pull it into this workspace. Brendan pushed his own variation of the bugfix to the Crew Repository at 06:09:35, and I merged the two at 06:24:47 :-)


12 thoughts on “Distributed Development with Mercurial in Action

  1. agorf

    Distributed version control systems look really promising… I realised that after watching Linus’ presentation on git, at Google, in which he mentions quite a few reasons about why they are better than centralized ones. Of course, I wasn’t convinced to switch from Subversion since I use it locally (and many of these reasons do not apply), but I really believe any project involving more than one person should be version controlled with a distributed VCS.

  2. keramida Post author

    There are aspects of distributed SCM/VCS that are “different”, in the sense that they may seem completely alien and bizarre at first.

    The basic ideas behind distributed development fit very nicely with the way many free software and open source projects work, however, so I think we will begin seeing more and more FS/OSS projects adopt dVCS systems.

    I work for a company which internally uses Perforce as a centralized SCM system. Knowing how to work with CVS, Perforce, Subversion and now Mercurial (among others), means I get to see pretty often how developers work with source code management systems. Some times I feel really and honestly very angry when:

    * People commit stuff that is half-done and break everyone else’s workspace

    * People fail to commit often enough, and lose some changes because they run “p4 sync” at the wrong time

    * People fail to commit often enough, and lose local changes when they run “p4 merge” and mismerge something

    Mind you I don’t feel angry at my fellow developers. No, that would be a shame.

    I get angry at the lack of support from Perforce for a better model of working: for committing often local changes, pulling and merging from each other without the fear of losing work, for the lack of the ability to work offline, for the horrendously slow speed of Perforce over a slow network link, etc.

    All these are areas covered nicely by Mercurial and a more distributed SCM system.

    When Mercurial grows a nifty GUI interface for Windows (like TortoiseHg), a portable and graphical merge tool (like gpyfm), and a neat-looking history browser (like a GTK+ based version of the current Tcl/Tk-based history viewer), I swear to you I’m going to help everyone at work migrate to Mercurial :D

  3. agorf

    I see you mention Mercurial a lot. Have you checked out git? Have you seen Linus’ presentation that I talked about?

  4. keramida Post author

    Git is interesting. It started being developed about the same time as Mercurial/Hg too. Their feature lists are more or less the same and their speed for most operations is similar. They are both distributed, and they both include excellent support for merging multiple heads.

    But there is something about Git which I don’t think I like. It more or less demands developers to use some variation of UNIX. Mercurial has, IMHO, much better potential for supporting Windows users, and I like that a bit.

  5. keramida Post author

    Right… “Who needs WIndows anyway?” is a nice joke, but it reminds me of why I don’t like everything Linus said in his Google speech. This “holier than thou” attitude is fun and amusing in Linux User Group meetings, but when you have to support the version control and source code management needs of a commercial company, with several projects running on multiple platforms (Solaris, Windows, mobile devices like cell-phones), the joke gets old pretty fast.

    “Half of our projects at work need Windows” is a valid reply, in this case :-)

  6. agorf

    I understand that working in a company requires some compromises (using Windows) but I don’t see why you can’t use git on (open-source) software projects of your own where you get to say what gets used and what does not? I’d too use a VCS like Mercurial in a similar environment but I don’t reject git just because it isn’t Windows-oriented.

  7. keramida Post author

    I didn’t dismiss Git altogether so far. I have a local installation of Git on my laptop, and I experiment with it now and then. Let’s say that lack of Windows support is not _the_ only reason why I’m not using it more often; it’s merely one of the reasons.

    I kind of like the idea of Git’s local branches, and I’m learning how tags work in Git. It is interesting as a system, but I need a _very_ good reason for using it at this point. I’ve worked with at least the following so far:

    CVS for FreeBSD.
    Subversion for personal stuff at work.
    SVK for personal stuff at work
    Perforce for FreeBSD
    Perforce for work
    Git for personal stuff at work, running on Solaris
    Mercurial for personal FreeBSD patches
    Mercurial for personal stuff at work
    Mercurial for preparing patches, which get committed to Perforce, at work

    Having to learn the command-line UI of all these, the CLI of Git strikes me as a particularly bad example of how commands should appear. I hear that things have improved significantly with Git 1.5.x but I haven’t really installed it on the Solaris and BSD systems I use for development. One of the reasons why I haven’t installed it yet is the big list of dependencies.

    The requirements of Mercurial are pretty much:

    Do you have Python 2.3 or newer? Cool, you can install Mercurial then.

    Constrasted with the array of libraries, shells, and other tools Git needs to run, this is a surprisingly small set of requirements, and a very easy one to fulfill too :-)

    So we basically have three reasons why I personally prefer Hg over Git so far:

    The Git team doesn’t seem too eager to support Windows any soon now
    Very easy to grasp and intruitive command-line UI
    Very short and easy to install list of dependencies for a basic setup

  8. Patroklos Argyroudis

    It is a miracle how you don’t drive yourself crazy working with all these different SCMs, which not only have different interfaces, but, most importantly, in some cases have different functional models as well. Unless, of course, you have created the one true interface to bring-them-all-and-in-the-shell-alias-them. Seriously though, I have been recently tempted to switch to Monotone; any specific reasons to choose Mercurial apart from the fact that it is written in Python?

  9. keramida Post author

    The one reason why Mercurial is better than Monotone is:

    “””Raw speed.”””

    I’ve tried using Monotone to check out the source tree of Pidgim, after a friend did it at his home.

    I can tell you that this is one of the worst experiences I’ve ever had with an SCM system. The sheer complexity of fidding with ‘databases’ and schemas and all that stuff is completely insane.

    Then you start checking files out… and you realize that while Monotone has some very neat ideas about distributed development, it is (to use the words of Linus) so “horrendously slow” that it’s unbearable.

    I have been watching the development of Monotone with a much more scrutinous eye during the last 4-5 months though, They have made some improvements in the speed department, and I will definitely try to check it out at least another time during my summer days off :)

  10. Patroklos Argyroudis

    After almost ten days of working with Mercurial (for my personal work, our research group uses CVS) I must admit that I am impressed. Thanks for the tip (pun intended ;)

Comments are closed.