Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)

[Stephen Leake]

Markus Wanner <address@hidden> writes:

>> No, the user asked for the deletion once, and for the modification once,
>> in parallel. (In reality, that could be done by two different users on a
>> team.)
>> 
>> That's a conflict.
>
> I can understand this viewpoint, now.

Ok, good.

>>> Sure. The same can be said for intentional deletes: Sometimes the drop
>>> is intended, and it needs to persist; the easiest way to achieve that is
>>> die-die-die merge. Neither of these two options is a reason to always
>>> prefer one over the other.
>> 
>> Exactly; that's why it needs to be a conflict, so the user makes a
>> concious choice to affirm either the drop or the modify.
>
> Agreed. But if he needs to do so, he shouldn't have to repeat his
> decision over and over, again. That's what I'm opposing to. 

Yes, that makes sense.

Which is why I proposed a couple of ways to do that; add an attribute or
a workspace option. I don't think you responded to that proposal.

>>> Ever thought of what happens with modifications on both node-ids after a
>>> 'keep' resolution, but before merging?
>> 
>> I don't understand what you mean by 'after a resolution but before
>> merge'; the conflict resolution happens during a merge; there is no
>> opportunity for the user to modify nodes (other than providing the file
>> content for the conflicted file).
>
> Sorry, that was too brief. I'll give an example:
>
>     A
>    / \
>  M1   D
>   | \ |
>   |   P    -- P is the "keep" resolution, effectively resurrecting
>   |   |    -- the file and giving it a new node id.
>   |   |
>  M2   |    -- M2 and M3 are both modifications on the same file (but
>   |   M3   -- now known under different node ids).
>    \ /
>     Q      -- Q merges. How?
>
> The issue you are facing in Q is that monotone thinks the two node ids
> are distinct files. Even if you manage to teach it to "suture" because
> the two files conflict by their path, figuring out what ancestor to use
> is non-trivial. And certainly involves remembering the relation of the
> file added in P to the one deleted in D (or modified in M1, same thing,
> same node id).

Another good test case. But I think my current solution addresses it;
the conflict data in _MTN/conflicts has the file_id of the file in M2
and M3, so the user (or a front-end) can retrieve them, diff them, and
use the 'user' resolution to provide the content for Q.

> Doesn't this problem equal to suturing?

That would be a better solution.

> Let's adding a simple rename:
>
>     A
>    / \
>  M1   D
>   | \ |
>   |   P    -- P is the "keep" resolution, effectively resurrecting
>   |   |    -- the file and giving it a new node id.
>   |   |
>  M2   |    -- M2 and M3 are both modifications on the same file (but
>   |   M3   -- now known under different node ids).
>   |   |
>   R   |    -- R additionally renames the file on the left
>    \ /
>     Q      -- Q merges. How?

In this case, the current conflict code will identify M3 as the node to
merge with R, which is the right thing to do. The reverse case is
different:

     A
    / \
  M1   D
   | \ |
   |   P    -- P is the "keep" resolution, effectively resurrecting
   |   |    -- the file and giving it a new node id.
   |   |
  M2   |    -- M2 and M3 are both modifications on the same file (but
   |   M3   -- now known under different node ids).
   |   |
   |   R    -- R additionally renames the file on the right
    \ /
     Q      -- Q merges. How?

Now there's no way to associate R with M2, so the drop/modified conflict
is repeated, and the user is not presented with all the information they
need (they should merge M2 with R). This is bad, and sutures is the
right fix.


But none of this is new; all of these cases exist in mtn 1.0, with all
of the same solutions, workarounds, and problems. I'm just making a
couple of the more common cases easier to deal with. And, unfortunately,
your favorite use case harder to deal with. So we need to address that.

-- 
-- Stephe