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

Hi,

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.

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

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?

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.

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

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

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.

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

Ever thought of what happens with modifications on both node-ids after a
'keep' resolution, but before merging?

Regards

Markus Wanner