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

[Markus Wanner]

Hi,

On 06/07/2012 01:16 PM, address@hidden wrote:
> Agree.  I remember wanting to be notified properly with a conflict when I 
> first ran into this.

Sure, there's a use case where it appears to be a conflict. And I've run
into this as well.

However, another perfectly valid use case is wanting to permanently
delete a file in a child branch, which might continue to get modified in
the parent branch. You'd not want that to conflict every time you
propagate, do you? (The warning is annoying enough, already).

Ultimately, it turns out that there are two distinct ways to think of a
delete. My way of looking at it is that a delete - just like a rename -
is just a change to how the file's content can be reached. It doesn't
change it nor does it conflict with modifications thereof. An un-delete
will simply make that file visible, again - possibly including merged
stuff. Let's call that variant A).

The other way of thinking of a delete is that it also truncates the
file's contents, which is a modification of the file's contents and
certainly conflicts with other modifications. The user might then expect
an un-delete to restore the exact contents of the file as it was just
before the delete. Let's call that variant B).

(At the moment, manually truncating a file before deleting it doesn't
help avoid the warning. Monotone only cares about the content conflict
just before the delete, if you merge the truncating revision separately.
Otherwise, the delete takes precedence).

We could allow a single revision to "patch" a file to zero length before
deleting it. Therefore store the users wish for that delete to conflict
with modifications of the file. In such a case, monotone should clearly
raise a merge conflict against modifications of that file.

However, I'm concerned about how to expose these two kinds of deletes to
the user. I don't expect the average user to be able to understand the
difference. Certainly not at the point in time of the delete. Maybe at
the point in time of a merge (which currently emits the warning).

Maybe, the user even wants different revisions to merge differently for
the same deleted file. So it's not a property of the delete, but... of
what else?

Regards

Markus Wanner