Mercurial Workflow advice

Question

I'm after a bit of advice for using Mercurial.

We currently use CVS on a central server, and maintain a head branch and a couple of past version branches. Our workflow is that all fixes/new features are implemented on the HEAD, and then when creating releases on any of the branches, we would effectively pick and choose the files we require to be included on the branch, and move the branch tag to incorporate these files, then go and build the release (and tag it).

I'd like to implement a similar workflow in Mercurial. However, I'm not sure it would be possible to pick and choose specific fixes(changesets) from the default branch and apply them to one of my release branches. What I have seen is people applying fixes to their branches and then pulling these into the default branch. Is there a way I can mimic our CVS workflow as described above using Mercurial?

Answer 1

In my experience, and in my understanding of the collective distributed version control users' experience, the problem is that cherry picking changesets is (and actually always has been) a recipe for merge conflicts. Essentially, by trying to implement changes on the newest code and "backport" them to older code, you're forcing yourself to have to redo the same merges over and over again.

Imagine that you are maintaining three releases Head, Head-1, and Head-2. In Head-1 you implemented a major refactoring change. Now you implement three new features in Head that you want to include in Head-1 and Head-2. Since Head and Head-1 both have the same big refactoring, the merge of the new features into Head-1 won't be all that complicated. However, to merge the new features in Head-2, you'll potentially have to resolve the exact same merge conflicts across all three features to get around the major refactor.

The truth is, you're probably already doing this -- you're just not aware of it because CVS doesn't help you with the merges in the other direction either. Newer version control systems like Mercurial and Git can make the "forward" direction merging much, much easier.

So instead of implementing the three features in Head in Mercurial, it would be better to implement the changes in Head-2. Since the merge information is already captured in the graph model, most likely the merges to Head-1 and then Head will be quite easy.

I'm not saying that what you're asking for can't be done -- you could use things like the transplant extension to implement your model -- you just wouldn't be taking advantage of Mercurial's excellent merging power if you do so and you would be making a lot more work for yourself and your team.

Answer 2

It heavily depends on what your 'past version branches' actually are, but I think you should adopt a different workflow when migrating.

Think of merging branches as of merging rivers: everything that was in one is in the other as well, after you merge. That's why if you want to implement a feature that should end up in several branches, the suggested way is that you implement it in one of them, and then merge it into others. It's very important to understand that everything that was in the source branch will end up in the target branch, not just the feature you implemented.

So it's reasonable to have past version branches to form a matryoshka doll. For example, you have three long-lived branches: 1.x, 2.x, and default. All of the features in 1.x are also present in 2.x and default, all of the features in 2.x are also present in default. (Here, default is a stage for your next major version; you create a new branch 3.x when you release v3.0.)

So, if you want to make a new feature in 1.x, you implement it there and then do two merges: 1.x into 2.x, then 2.x into default (this is forward-porting). If you try to do it the other way round, in default (that's back-porting), you won't be able to merge default into either 1.x or 2.x, because default has a lot of other stuff that shouldn't appear in older version. It's hard to go against the flow, so you'll have to transplant the necessary changes back to 1.x and 2.x, which most probably won't apply cleanly, and you'll be basically doing by hand things that Mercurial could do for you.

You may take a look at the layout of the Python repository, explained in the dev guide.