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

[Stephen Leake]

Markus Wanner <address@hidden> writes:

> Hi,
>
> On 06/09/2012 03:19 PM, Stephen Leake wrote:
>> Markus Wanner <address@hidden> writes:
>>> 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.
>
> Conflict data in _MTN/conflicts? Hm.. I didn't ever see or use that.

That's what 'mtn conflict' uses by default.

How do you resolve conflicts?

> So, you are effectively saying, monotone doesn't need to properly keep
> track, but the user can resolve it. Sorry, I just don't consider that to
> be a "solution".

We've agreed that suture is the ideal solution in this case. But no one
is volunteering to implement suture (I'm the only one that has actually
tried). So we are looking for a compromise.

I'm saying monotone reports a conflict, and provides all the
information the user needs to properly resolve it. That is an
improvement on what it does in mtn 1.0, which is to report the problem
in a warning, but provide no help in resolving it in the case where the
delete was a mistake. 

See below for more on this.


>>>     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:
>
> Huh? How can it do that? The two files have different node ids,
> different names (and different modifications applied to them).

You may be right; implement the test case in nvm.issue-209 and see what
happens.

> Oh, you mean M2 conflicts *again* with the delete? But a user already
> decided he wants to keep the file (and apply M1). That should merge
> cleanly with yet another modification.

As we have been saying, the user currently has no way to tell mtn that
decision should be remembered, and applied the next time the same
conflict occurs.

In the other thread, we are discussion a mechanism to solve exactly that
issue.

>> 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.
>
> It's not just that the user is not presented with *all* the information.
> He gets misleading information - instead of the clear warning that
> monotone-1.0 provides.

See below for mtn 1.0 and nvm.issue-209 test cases that address exactly
this issue; please explain in detail why nvm.issue-209 is 'misleading'.

>> 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.
>
> I disagree here. It's not just my favorite use case that gets harder.
> It's the die-die-die behavior (and thus the "keep" resolution to the
> drop/modified conflict) that gets obscured. I'm not in favor of such a
> thing.

I don't understand what you mean by 'die-die-die behavior gets
obscured'.

The user deleted a file by mistake. mtn has no clean mechanism for
undoing that, but it does have a reasonable workaround. I think you are
saying that using that workaround 'obscures die-die-die behavior'. Ok,
that's true. Why is that a problem? It is consistent with mtn in
general, and it is what the user wants. More importantly, it is not new;
it has been in mtn all along.

The 'keep' resolution in nvm.issue-209 is just the workaround formalized
and made easy. 

Attached is a mtn 1.0 test script that shows this use case:

--     A
--    / \
--   M1  D
--   | \ |
--   M2  P
--    \ /
--     Q

Compare this to
nvm.issue-209/test/func/resolve_conflicts_dropped_modified_2/__driver__.lua

The semantics are the same; only the user interface is different.


You've agreed this is a valid use case; what mechanism would you propose
for it, since you don't like this one?

--
-- Stephe

__driver__.lua
Description: Binary data