Re: Maintaining branches...

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Sat, Jun 16, 2001 at 09:25:10AM -0700, Paul Sander wrote:
>> If I understand you correctly, what you want is this:
>> 
>> Merge 1:
>> specification - version 1.4 = 1.3 + ( 1.1.0.3 - 1.1.0.2 )
>> result - version 1.4 = 1.3 + ( 1.1.0.3 - 1.1.0.2 )
>> 
>> Merge 2:
>> specification - version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 )
>> result - version 1.5 = 1.4 + ( 1.1.0.5 - 1.1.0.3 ) + ( 1.1.0.2 - 1.1 )
>> 
>> Is this correct?

>Correct.

>> What about the case where the first merge is a partial, where the result
>> (version 1.5) contains only a subset of the deltas between 1.1.0.3 and
>> 1.1.0.2?  In this case, applying all of (1.1.0.5 - 1.1) to 1.4 and resolving
>> conflicts seems like the right thing to do.

>Except that I would expect that there should be no conflicts (stemming from
>the re-application of a set of changes any).  

There may not be repeated conflicts (between deltas already applied during
successive merges), but on the other hand some of the deltas between
1.1.0.2 and 1.1.0.3 would be skipped during the second merge.  This is
probably an intolerable situation.

>That's why I think it should be a multipass system.  1.1.0.2 - 1.1 as one
>diff, 1.1.0.5 - 1.1.0.3 as another set of diffs.

>I would imagine that the sets of diffs would be built up, and applied in
>turn.  As each set was applied, whatever necessary tracking would be done
>in local files.  And as soon as any conflict occurs, patching would stop.
>This could result in an incomplete application of patches, but there is
>nothing to prevent the process from picking up where it left off after
>resolution.

I don't believe we're talking about tracking individual deltas here, just
tracking which versions contribute to each merge.  In that light, I don't
see how what you propose could be done.

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