On Thu, Jun 14, 2001 at 04:48:33PM -0700, Paul Sander wrote:
> >--- Forwarded mail from [EMAIL PROTECTED]
> >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. [EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs