Re: Maintaining branches...

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Thu, Jun 14, 2001 at 04:48:33PM -0700, Paul Sander wrote:
>> >--- Forwarded mail from address@hidden
>> >But consider the following sequence:
>> > 
>> >branch at 1.1.  Branch has 1.1.0.1 and 1.1.0.2.
>> >
>> >1.1.0.3 is made, and that particular change is needed immediately on the
>> >branch branch, so only it is moved over.  So 1.2 == 1.1 + 1.1.0.3.
>> >Changes 1.1.0.4 and 1.1.0.5 are made.  Now we want to migrate all of those
>> >changes onto the main branch.
>>
>> I believe the desired behavior really is this:
>> 
>> First merge:
>> version 1.2 = version 1.1 + ( version 1.1.0.3 - version 1.1 )
>> 
>> Second merge:
>> version 1.3 = version 1.2 + ( version 1.1.0.5 - version 1.1.0.3)
>> 
>> Is this correct?

>That's what I thought at first, but now I believe he really does
>mean:
>    First merge:
>    version 1.2 = 1.1 + (1.1.0.3 - 1.1.0.2)

>    commit trunk-only revs 1.3 and 1.4

>    Second merge:
>    version 1.5 = 1.4 + (1.1.0.2 - 1.1) + (1.1.0.5 - 1.1.0.3)
>                = 1.1 + (1.4 - 1.2 [sic]) + ( 1.1.0.5 - 1.1)

>And even if he doesn't mean that, it's a case that seems worth
>discussing.  Say you have the familiar situation of Release-2
>development on the trunk, and a Post-Release-1 bug-fix branch B.
>Someone fixes a bug on B.  Then, before the team is ready to cope
>with a wholesale merge, it's discovered that that particular bug
>is a showstopper for continued trunk development.  So you want to
>merge that bug fix only, but keep the rest of the fixes on B
>isolated until a later date.

Your first case is really two merges, one requiring the user to supply
version 1.1.0.3 as the common contributor.  The other is a single join
with version 1.1.0.2.

You could also do this:

version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 )

And then resolve the inevitable conflicts resulting from the first bug-fix
merge.  This is how CVS currently works.

>--- End of forwarded message from address@hidden