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

[Stephen Leake]

Markus Wanner <address@hidden> writes:

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

I don't see this as a valid use case; can you elaborate?

Hmm. I can imaging having win32 and unix support in the parent, and
dropping win32 in the child.

My prefered solution for that case would be to split the project into
five (or more) projects; win32 support, unix support, common
project; release project 1 contains common, unix, and win32; release
project two contains common and unix.

But it's easier to use directories and build directives to achieve that
result, so I'm back to thinking this is not a valid use case.


Assuming for the moment it is a valid use case, one way to handle it is
to put an attribute on the file (in the parent branch) that indicates it
is permanently deleted in the child branch, and have the conflict
detection code honor that attribute.

That is a mechanism that allows the user to inform mtn about their
considered resolution to the on-going conflict.

Another way would be to put some option (like --no-dropped-modified, or
perhaps "--resolve-dropped-modified <file> drop") in the workspace
options file for the child branch. Not as good as an attribute, because
it's not in the database.

Note that file suture is no help in this case.

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

I've never thought of it that way.

Delete changes the file from "can be reached" to "can't be reached".
Rename changes the file from "can be reached via path A" to "can be
reached via path B".

If the file contains C code, and other C code depends on it, the
delete will be noticed at build time.

Rename would also be noticed at build time, but it is easy to make
additional changes to restore consistency: fix the 'include' statements,
or the makefile list of object file names.

Restoring consistency in the delete case would mean bigger changes.

If nothing else in the project depends on the deleted file, so neither
delete nor rename (nor modify, for that matter) would be noticed,
perhaps it should be in a different project (as with win32 above).

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

That's been my model.

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

right.

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

I don't understand this.

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

Perhaps my attribute proposal above would work?

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

I don't know :).

--
-- Stephe