Re: Maintaining branches...

[Eric Siegerman]

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.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)