managing multi-version development with mercurial

[Christian Boos]

Alexander Schatten wrote:
> Sorry, now I have to add a probably dumb question to this thread. Actually about the "merge" suggestions. I wonder how merges could help; let me explain my question:
>
> Assume 
>
> (1) I have V1, then code develops to V2.
>
> (2) Now, a bugfix is needed in V1 that generates V1.0 --> V1.1; this bugfix is *not* needed in V2, because it already changed to V2.2 and this bugfix is not relevant any more
>
> (3) I Update V2.2 on multiple steps to V2.5
>
> (4) Another bugfix is needed and makes:V1.1 --> V1.2; now THIS bugfix is also needed in V2.5
>
> Now, these two branches are significantly different. A merge from 1.2 --> 2.5 would, as I understand it also add the changes from 1.0 --> 1.1, and these I do most likely not want in Version 2.
>
>
> I believe, this is a pretty usual scenario, no?
>
> Do I get something wrong here?
>   

That you're not forced to merge V1.x wholesale. You can do it in two 
steps: first up to V1.1 ignoring the changes, then up to V1.2, taking 
the changes.

Example (assuming you're using tags for the above):

$ cd V2.x

You're now in your V2.x repository, at tip.
If you don't have yet the changesets from the V1.x branch in your V2.x 
repository, do:

$ hg pull ../V1.x

Now tell Mercurial to merge up to V1.1, but ignoring the changes:

$ hg --config ui.merge=internal:local merge -r V1.1

There are a couple of variants to achieve this, look in the archive:
HGMERGE=internal:local hg merge -r V1.1
HGMERGE=true hg merge; hg revert -a -r V2.5

Verify that you have no actual changes:

$ hg diff
$ hg ci -m "Merge with V1.1 - record only"

Now do the same thing with V1.2, except this time do a normal merge to 
take the change you're interested in.

$ hg merge -r V1.2
$ hg ci -m "Integrate bugfix from V1.2"


Of course, this only works that smoothly when you don't have too many 
changes on V1.X and when you can do a simple choice (ignore/take) across 
those versions. In case you have lots of changes on V1.X, and when 
you're not always sure if a given changeset from V1.X will have to go 
one day to V2.X or not, it becomes more tricky. Once you do a "record 
only" kind of merge, this prevents you to reintegrate any older 
changeset from that branch at a later point (as you'd get the "abort: 
can't merge with ancestor" error). If you really need to do it, you'll 
have to use an other means to replicate those changesets (hg export / 
import, or the transplant extension).

In an environment where many people are committing fixes to a V1.X 
branch, I'm not sure the method I presented above will scale. The need 
to merge those changes to the V2.X branch in order, making each time the 
right decision, can be quite challenging. This is were I find the 
Subversion approach, using the svn:mergeinfo property, quite pragmatic 
and perhaps a bit more convenient for people (each developer can merge 
its own changes when they see fit). Of course, this is ignoring the 
terrible slowness of svn merge for a moment ;-)
Now if someone has setup a workflow (perhaps using transplant?) where 
this can be achieved as easily with Mercurial, I'm all ears, as this is 
what essentially prevents me to "sell" Mercurial for a wider usage at my 
workplace...

-- Christian