Mercurial：跨版本合并/大规模采摘樱桃

Question

Situation

We have 2 versions (1.0 and 2.0) of a project that are both actively maintained. It is basically the same project (as far as changes go), but being based on different base versions (base1.0 and base2.0). Everything that is changed in 1.0 has also to be ported to 2.0. The same goes for base1.0 and base2.0.

In mercurial we have 4 branches: base1.0 , 1.0 , base2.0 and 2.0 . Something like this:

                         __2.0
             __base2.0__/
            /
__base1.0__/___1.0____________

Now everytime we change something in the base version, we make the change in base1.0 and do a hg merge to base2.0 . No problems here.

Now when we do the same for 1.0 and want to merge them into 2.0 , we also have to re-merge the entire base1.0 branch into 2.0 , although that has already been done creating base2.0 out of base1.0 .

Question

What is the most efficient way to solve this? I had a few approaches:

1. Merge : as explained above, this causes a lot of overhead and work to be re-done that has already been done
2. graft aka cherry-pick: Select every single change we make on 1.0 and port them to 2.0 using hg graft. While it does work in some cases, it creates duplicate changesets because it ports them 1:1. What I'd like would be 1 single commit containing all updates made on 1.0 grafted to 2.0 .
3. diff export : I also tried to make a export a diff between the original 1.0 and the most recent 1.0 and then import it onto 2.0 . But it's a patch, and patches are evil. And not very handy to handle.

Any ideas? Being relatively new to the whole SCM concept I just wanted to hear what others do in such scenarios. Thanks.

Answer 1

I actually resolved my problem. I'll add it as an answer, maybe someone else finds it useful.

What I really needed was cherry-picking all my changes from 1.0 to 2.0 . hg graft does that pretty well, but creates an additional commit on 2.0 for each changeset grafted and messes up my graph.

So what I did was creating a clone of my repo and then grafting all the changesets using hg graft from 1.0 onto 2.0 . Then I exported a diff of pre-graft and post-graft and imported that diff as a patch onto the original repo.

Essentially a cumulative "graft" without any information about where it came from. This was exactly what I needed and worked for me in this case.