[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-devel
Subject:    [darcs-devel] [patch1872] regard explicit dependencies as resolving conflicts
From:       Ben Franksen <bugs () darcs ! net>
Date:       2019-08-31 8:22:04
Message-ID: c430f416-1a1d-459b-c424-1abc5532cadc () online ! de
[Download RAW message or body]


Ben Franksen <ben.franksen@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@darcs.net>
<http://bugs.darcs.net/patch1872>
__________________________________
_______________________________________________
darcs-devel mailing list
darcs-devel@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-devel
[prev in list] [next in list] [prev in thread] [next in thread]