[darcs-devel] [patch1946] WIP: introduce concept of unwinding a conflict

[Ganesh Sittampalam]

Hi,

On 20/01/2020 15:05, Benjamin Franksen wrote:

> sorry for dropping out of darcs development for quite a while, in
> particular for not responding to this message earlier.

No problem, I've been doing other things for a while too.

I have posted my current draft code here:

https://hub.darcs.net/ganesh/darcs-unwind-draft-20200126

As usual it'll take me a while to clean this up for submission.

> Am 05.12.19 um 08:16 schrieb Ganesh Sittampalam:

>> The upshot is that I have an implementation of fullUnwind that works for
>> V2 and V3 patches but fails for some V1 patches.
> 
> Hey, that sounds pretty good.
> 
> Which features are used to achieve this? To elaborate, suppose, for the
> sake of discussion, we disregard V1 and V2, could the squashing /
> reordering be done with /named/ prim patches a la V3 alone? If not,
> which methods from the raw prim patch interfaces are you using?

I rely on Commute, Eq2, and Invert - see mkUnwound and squashUnwound here:

https://hub.darcs.net/ganesh/darcs-unwind-draft-20200126/browse/src/Darcs/Patch/Unwind.hs

Does that answer your question?

>> For the V1 failures, I have a test case with 5 patches where the effect
>> of the two routes through a merge square is different, even after
>> collapsing inverses and commuting. I think this is a clear bug in V1;
> 
> IIUC, you claim there are situations where we have patch sequences p and
> q, such that
> 
>   merge (p:\/:q) = q':/\:p'  &&  effect (p:>q') /= effect (q:>p')
> 
> This is definitely a bug.

Correct, that's what I claim. See example4guts and below here:

https://hub.darcs.net/ganesh/darcs-unwind-draft-20200126/browse/harness/Darcs/Test/Patch/Unwind.hs#207

Ganesh