[darcs-devel] musings about darcs-3

Ben Franksen ben.franksen at online.de
Sat Feb 24 18:04:18 UTC 2018


Am 22.02.2018 um 08:04 schrieb Ganesh Sittampalam:
> On 20/02/2018 09:02, Ben Franksen wrote:
> 
>> The above should sound familiar. In fact there are striking similarities
>> between conflictors and these new merge patches. For instance, both
>> first annihilate the effects of both sides of the conflict and then
>> apply the resolution on top of that. However, there are also conceptual
>> differences: a conflictor represents one of two conflicting patches,
>> whereas a merge represents only itself and exists in addition to the
>> conflicting patches. This is a more symmetric solution. Also, with
>> conflictors we apply both the original patch and the one that conflicts
>> with it. With merges we don't: we only ever apply one branch or the
>> other; the merge "preparation" sub-patches on each branch make sure that
>> it makes no difference which one we take.
>>
>> The commutation behavior of the core of the merge patch is very simply
>> defined by its (explicit) dependencies. We want to keep this set as
>> small as possible, so before we create the preparation patches, we
>> should try to pull across any patches which merge cleanly, then commute
>> the common ones "out" to the common trunk.
> 
> [snip details]
> 
> Interesting idea - one question is what happens when you merge two of
> these merge patches?

As far as I can see this is covered by the rules given so far, no
special treatment needed. When I pull a merge patch, it pulls along its
two parent branches. If the merge conflicts with anything I have locally
(including an existing merge), this will create yet another branch and I
have now again "two heads" which I can merge, etc.

Cheers
Ben



More information about the darcs-devel mailing list