Working in a Mercurial World
By kto on Oct 31, 2007
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.