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

[Stephen Leake]

Markus Wanner <address@hidden> writes:

> On 06/06/2012 02:33 AM, Stephen Leake wrote:
>> Yes, but it's the same node that the drop-modify 'keep' resolution would
>> add.
>
> Yeah, I'm assuming Q to be the result of the drop-modify 'keep'
> resolution as well.
>
>> In the P/Q merge, the same conflict occurs; the original foo node in Q
>> is dropped. But the resolution would attempt to create the new foo node
>> in Q, so instead it reuses it.
>
> Ah, right, each modification conflicts with the delete over and over
> again. I didn't think of that part. So the file isn't even properly
> resurrected, but every modification on the parent branch leads to a new
> drop/modify conflict, for which the user needs to re-iterate his
> decision. Awkward.

Yes, suture would be better (which is something we agree on :).

>> Since the current behavior is not what I want, I think it should be a
>> conflict, so the user can choose the current behavior (the 'drop'
>> resolution to the conflict), or something else (the 'keep' or 'user'
>> resolution to the conflict).
>
> AFAIU your proposed approach makes the 'drop' choice non-permanent. In
> that aspect, the user cannot choose the current behavior anymore, no.

I don't see how I'm changing anything.

The drop is only non-permanent if the user decides it was a mistake. In
mtn 1.0, you can re-add the file; the consequences of that are exactly
the same as choosing a non-drop resolution of the drop/modified
conflict; that is my definition of the resolution.

The point is that with the conflict process, the user is presented with
an explicit choice. With mtn 1.0, the warning message is all you get;
going back and adding the file with the proper contents is more
awkward than with the conflict.

> Working around the drop/modify conflict by manually re-adding the file
> is a once-per-erroneous delete operation. How can the user work around
> the "cannot-drop-persistently" issue that your approach would introduce?

I'll have to write up the same scenario in mtn 1.0 and with the
drop/modified conflict to illustrate this.

> Admittedly, with the current approach, you'll also see the drop/modified
> warning once-per-modification on an intentionally deleted file. But it's
> just a warning, no user action is required, the file remains deleted, as
> the user asked for.

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.

> Overall, this doesn't look like a win to me.

We need some input from others.

We could consider a user option "--no-dropped-modified" to retain the
mtn 1.0 behavior. Then we get to argue over the default value for that :).

>> The reason I don't like the current behavior is that sometimes the drop
>> was a mistake, and it needs to be corrected; the easiest way to bring
>> that to the user's attention is via a merge conflict.
>
> 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.

> The current approach (die-die-die together with the warning) being
> easier to handle (and work around, if necessary) *is* a reason for that
> option, though.

It is certainly easier to handle if you want to confirm the drop; just
ignore the message.

I don't see how it is easier to 'work around', which means confirm the
modify. I'll have to write this up explicitly.

The conflict process makes both choices equally easy.

>> Yes, by the file name, which is why it looks like a duplicate name conflict.
>> 
>> It will be a problem if the file is renamed between P and the merge.
>
> Yeah, the 'keep' resolution might not be able to *add* the file again
> under the same name, because such a file already exists. It's not a
> duplicate name conflict because of the merge, but one that arises by
> resolving the drop/modify conflict that way.

I've just started working on this case. I think I need to add the new
node with the same name to the conflict itself, so the user can diff all
three files (the dropped file, the modified file, and the new file)
while resolving the conflict. So it really does look like a
'dropped/modified, duplicate name' conflict. It might be useful to give
it yet another name; I'll see how the code works out.

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

-- 
-- Stephe