[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: Sat, 16 Jun 2001 10:29:26 -0700

>--- 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 + ( - )
>> result - version 1.4 = 1.3 + ( - )
>> Merge 2:
>> specification - version 1.5 = 1.4 + ( - 1.1 )
>> result - version 1.5 = 1.4 + ( - ) + ( - 1.1 )
>> Is this 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 and
>>  In this case, applying all of ( - 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 and 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 as one
>diff, - 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

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

reply via email to

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