Re: Updated Issue 209 - support drop/modified conflict (monotone)

Hi,

On 06/09/2012 03:19 PM, Stephen Leake wrote:
> Markus Wanner <[email protected]> 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.

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".

>> 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:

Huh? How can it do that? The two files have different node ids,
different names (and different modifications applied to them).

Say A has the original file "foo", node id 2. Merge P "keeps" that file
"foo", by adding it under node id 3. Following a modification on each
side. After the rename in R, node id 2 is now known under the file name
"bar".

So the merger that needs to create Q sees a file "bar" with node id 2 on
the left and a file "foo" with id 3 on the right. How do these conflict?
(And what "current conflict code" are you referring to? The issue-209
branch?)

>      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

Yeah, the two files in R and M2 have no association. Neither file names
nor the node ids match. If you ask me, that's pretty much the same case
as in the example above.

> so the drop/modified conflict is repeated,

What drop conflicts with what modification? P "resolved" the one
conflict that I see. After that, monotone considers the file that P
(re)created to be a different one than what D deleted.

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.

> 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.

> 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.

Regards

Markus Wanner