[darcs-devel] [patch1872] regard explicit dependencies as resolving conflicts

Ben Franksen bugs at darcs.net
Sat Aug 31 08:22:04 UTC 2019


Ben Franksen <ben.franksen at online.de> added the comment:

>> This made me see a flaw in the algorithm, which I think can lead to an
>> unresolved conflict not being shown because it erroneously regards it as
>> resolved. Can you spot the problem?
> 
> Is it to do with the fact that even content-based dependencies at the
> Named level are less fine-grained than at the level of the contents of
> those Nameds, since a Named contains an FL? So if p depends on q by
> name, q depends on r by content, then r will end up in ctx. But if some
> element of r that *isn't* depended on by something in q has a conflict,
> we should perhaps regard it as unresolved.

Exactly. So if A1 and A2 are unrelated conflicted changes, B1 depends on
A1, but not A2, we have named patches A=(A1;A2) and B=(B1) and finally C
which depends on B by name. Then even A2 will count as resolved, which I
think is wrong.

The difficulty in fixing this is that we now need a way to pass the
information about which patches we /do/ know are resolved (all those
which are directly depended on by name) down to the resolveConflicts of
the lower layer. I think this requires another change to the API.

Or we pursue the idea of Dependors that capture explicit dependencies at
the RepoPatch level (that wouldn't work for V1 and V2, but perhaps this
is okay).

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1872>
__________________________________


More information about the darcs-devel mailing list