Kelly O'Hair's Weblog (blogs.sun.com)
Wednesday Oct 31, 2007
Working in a Mercurial World
So how do you work with a Distributed SCM? There are many answers, the easy answer is that you clone the forest, make the change in your local forest, create the changeset and push the changeset. Well, that works. But maybe you are working on multiple fixes, and you don't want to repeatedly clone over the network (even if it is fast), so here is another model similar to the way many of the Sun developers worked with TeamWare:
The "incoming" forest is effectively just a local clone of the team forest for TL (Tools & Libraries), or whatever team forest you decide your change belongs in. Note that this TL forest may be sparse, it depends on the team as to what portion of the MASTER forest the team forest will have. The fix1-fix3 are also local forest clones where you would might be working on specific fixes or features. Once a fix was finalized, reviewed, tested, and ready to go, you would create the changeset (or changesets) with an 'hg commit' and push the changeset to the outgoing forest. Depending on how long it takes for each fix will determine how often you may need to sync with the TL area via the incoming clone. You can push your outgoing changes in batches or as frequently as you'd want. Before pushing anything to a repository would require a sync with the parent forest of course.
Some people like to sync often, others wait until just before doing the push. One concern with Mercurial is that each sync may create a merge changeset, depending on whether anything is pulled over. So frequent sync's could create many unnecessary merge changesets.
My tendency is to investigate the Mercurial "mq" extension and see if the fix1-fix3 forests could just be one forest using the "mq" extension. See chapter 12 in the Mercurial Book.
-kto
Posted at 03:15PM Oct 31, 2007 by kto in Java | Comments[2]
Indeed, the MQ extension can help a lot with avoiding the proliferation of "useless merges".
I still like keeping separate MQ patch queues for each fix, so in my use-case for Mercurial with an incoming tree and an outgoing tree, there are still the following:
* incoming workspace
* outgoing workspace
* one workspace per bug/feature
The bug/feature workspaces have a local patch queue, which I push & rebase often.
When everything is done in fix1, I rebase the patch queue once more, to see if there are more merges to perform right before the final push, and then push to "ougoing" :)
Posted by Giorgos Keramidas on November 01, 2007 at 10:57 AM PDT #
Posted by Kelly O'Hair's Blog on November 01, 2007 at 06:20 PM PDT #