Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Markus Schiltknecht]

Hi,

Justin Patrin wrote:
> >  I'm thinking of suturing as an atomic "delete two, add one" operation.
>
> Except, of course, that the history points to both the deleted nodes,
> causing merging and such to work "properly", correct? It seems to be
> that implementing this as 2 drops and 1 add could be problematic in
> this kind of situation:
>
> A   B
> |\ /|
> | C |
> D   E
>
> A and B both have newly added files 'foo' with the same or different content.
> C is a sutured merge of the two.
> D has a content revision to 'foo' in A.
> E has a content revision to 'foo' in B.

Okay.

> If 'foo' in A and B has the same content and D and E make the same
> change this should all merge    cleanly to:
>
> A   B
> |\ /|
> | C |
> D | E
> \/\/
> F G
> \/
> H
>
> H which has the sutured file from C but the changes from D and E.

Depends on the changes, if this merges cleanly - as you describe below.

IMO this is yet another good example, why suturing needs to be symmetric 
(WRT the two file node ids). Otherwise, you'd loose one change.

> If 'foo' in A and B have the same content and D and E have changes in
> different       parts of the file, the merge should happen automatically to
> H with the sutured file having the changes in   both D and E.
>
> If 'foo' in A and B have the same content and D and E have conflicting
> changes then the merge will result in a content conflict which needs
> to be handled by the user, finally ending up with the sutured file
> with the changes. I suspect the same is true if A and B have different
> content in 'foo' as well.
>
> Repeat with instances of D and E having renames of the file.

Yup. Renaming seems easier, because renaming vs. suturing must be a 
non-content-conflict.

Merging contents is probably harder, because we suddenly have to care 
not only about one file (by node id), but with several. (I admit I 
didn't think too much about that, yet).

> And, of course, similar cases also apply for copy (mtn only allows
> rename currently), which is a lot like a 'reverse suture'.

Yes, that's why I'm thinking about copy at the same time as well. 
However, there are slightly different merge semantics. And as copy 
doesn't involve dropping any node ids, it's just a special kind of an 
addition.

(I'm talking about 'asymmetric' copies, where changes to the source are 
not propagated back to the destination file. That makes things a lot 
simpler.)

Regards

Markus