As usual, it's been a long time since I've blogged, but a lot of things have happened in the meantime.

Mercurial

I've been meaning to write up something about Mercurial and how it makes multi-branch development possible, even in a centralized environment. At rPath we regularly work with several branches of development of rBuilder. We use the same codebase for rBuilder Online and the version of rBuilder that we sell, but the Online version gets new features earlier than the shipped rBuilder appliance. To this end, we have one main repository hosted on our Mercurial server. Let's call it rbuilder. The team pulls from this centralized repository to do work:

hg pull
hg update
...do work...
hg commit
hg push default

This is our 'tip' repository, or in CVS terms, HEAD. Most major development goes on in this repository. When we are ready to push an update to rBuilder Online, we create a clone of the rbuilder repository on the centralized server, called rbuilder-live. This is basically the beginning of our code freeze for a site update. During the freeze period, new development can continue in the rbuilder repository, and any late-breaking changes go to both. To facilitate this, Mercurial has commands called import and export. We usually commit bug fixes to the rbuilder branch first, and then import them into the rbuilder-live:

cd rbuilder
hg export <changeset id of patch that goes in both repos< < /tmp/patch
cd ../rbuilder-live/
hg import /tmp/patch
hg push default

hg import parses the exported patch and includes both the commit message used for the first commit, as well as the user who did the committing. It doesn't matter who does the merge: the committer of the original patch is preserved. If we know that all of the changes in rbuilder need to go in rbuilder-live, I usually skip the import/export dance and use an extension called fetch:

cd rbuilder-live
hg fetch ssh://hgserver//hg/rbuilder/
hg push default

This imports all of the patches from rbuilder that do not yet exist in rbuilder-live. Once we have a well-tested codebase in rbuilder-live, we build a tarball, update the Conary package, and update the server.

We use the exact same methods to build our release code for the rBuilder appliance which we ship to customers. We call the repository rbuilder-2.1, referring to the major version of the code we are working on. We move patches back and forth as necessary. Keeping a 'stable' repository around for manipulation makes shipping incremental bug fixes easy--as long as we are diligent about committing code to the main tree, and if required, to the stable trees, we always have at least three well-maintained codebases that are easy to manage.

Mercurial also has a set of extensions called mq which I hear is a nice way to manage sets of patches and multiple repositories. I haven't explored these features, but I will as soon as I have a chance. Pachi also tells me there is an extension called forest which also helps solve this problem.

rBuilder Online Updated

Speaking of updating rBuilder Online, we added a couple of exciting features recently. We added support for Microsoft Virtual Server and Virtual PC images (VHD format), as well as similar support for Virtual Iron tools. Along with a number of search/browse improvements, we added a feature that allows project owners and developers to see downloads of their appliances over a period of time:

If you are a developer or owner of an rBuilder Online project, you can see this chart for your project by clicking on the Download Statistics link in the Project Resources. I hope this is an small incentive to publicize and promote your appliances!