managing multi-version development with mercurial

[Martin Geisler]

"Alexander Schatten" <ml_alexanderschatten at gmx.at> writes:

> Sorry, now I have to add a probably dumb question to this thread.

It's not dumb at all! I'll give you my suggestion below, but note that
this is mostly theoretical at this point -- I haven't had to do any
merges like this yet :-)

> 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

Okay, but I suggest you merge the branches anyway but throw away the
changes coming in from the V1.1 branch. That is called a dummy-merge:

  http://mercurial.selenic.com/wiki/TipsAndTricks#mergemineortheir

That will help below.

> (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

If you did the dummy merge above, you can just merge at this stage.

> 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.

Yes, a merge is a way of telling the world how you want to combine two
changesets. If one changeste is V1.2 and another is V2.5, then you'll
have to decide how you want to reconcile the differences between V1.2
and V2.5.

With the dummy merge, you'll only have to merge in the changes made
between V1.1 and V1.2, not the irrelevant change made from V1.0 to V1.1.

> I believe, this is a pretty usual scenario, no?
>
> Do I get something wrong here?


-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20091204/1801c88d/attachment.pgp>