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

[Markus Wanner]

Hi,

just briefly here, please see my other recent mail as well.

On 06/07/2012 11:22 PM, Stephen Leake wrote:
> Markus Wanner <address@hidden> writes:
>> 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 change is that the user would have to confirm that the deletion was
not just a mistake for every conflicting modification propagated. Where
as at the moment, she only gets a warning every time.

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

Exactly. (You effectively don't even want that, but you certainly don't
want a full-blown conflict each time).

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

I can understand this viewpoint, now.

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

Agreed. But if he needs to do so, he shouldn't have to repeat his
decision over and over, again. That's what I'm opposing to. (Aside from
implementation issues with your approach).

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

No. Die-die-die currently favors a "delete" decision. Your approach
would favor the "keep" decision. In somewhat different ways, though.

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

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

Doesn't this problem equal to suturing?


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?

By relying on name conflicts, you are implicitly saying this merge in Q
would be a clean merge. Effectively leading to a duplication of that
very file, just because somebody erroneously deleted it before. That
certainly doesn't match my (user?) expectation.

Regards

Markus Wanner