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:
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 :-)