[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maintaining branches...

From: Paul Sander
Subject: Re: Maintaining branches...
Date: Thu, 14 Jun 2001 16:48:33 -0700

>--- Forwarded mail from address@hidden

>On Thu, Jun 14, 2001 at 03:26:31PM -0400, Derek R. Price wrote:
>> Mike Castle wrote:
>> > And I think that this complete merging happens less than you might think.
>> >
>> > It cannot handle the situation where a specific set of changes is migrated
>> > before another (i.e., -j tag1 -j tag2).  It may not even be off of an
>> > immediate branch, but rather a couple over.
>> What can't it handle about this and why?

>Originally I was thinking only highwater marks.

>But I guess something like a .newsrc style range/set would work.  (Ok, what
>IS that data structure properly called?)

>But consider the following sequence:

>branch at 1.1.  Branch has and

> is made, and that particular change is needed immediately on the
>branch branch, so only it is moved over.  So 1.2 == 1.1 +
>Changes and are made.  Now we want to migrate all of those
>changes onto the main branch.

>So now we have to be able to tell cvs to:

>diff -r1.1 -r1.1.0.2, apply patch
>diff -r1.1.0.3 -r1.1.0.5, apply patch

I believe the desired behavior really is this:

First merge:
version 1.2 = version 1.1 + ( version - version 1.1 )

Second merge:
version 1.3 = version 1.2 + ( version - version

Is this correct?

If so, then the mechanism we're discussing will support this case.  Version would be recorded as an ancestor of version 1.2, which would later
be used to identify version as the common contributor for the
next merge.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]