>--- Forwarded mail from [EMAIL PROTECTED]
>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 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.
>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 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?
If so, then the mechanism we're discussing will support this case. Version
1.1.0.3 would be recorded as an ancestor of version 1.2, which would later
be used to identify version 1.1.0.3 as the common contributor for the
next merge.
>--- End of forwarded message from [EMAIL PROTECTED]
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
