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

[Markus Schiltknecht]

Hello Stephen,

sorry, I still didn't get around reading your initial plan on how to 
handle non-content conflicts. It's great you are taking care of this!

Stephen Leake wrote:
> The use case is that a file with the same name is added on two
> different heads (or branches), and then the heads are merged (or the
> branches propagated).
>
> There are two possible resolutions; the files should be "sutured" into
> one file, or the files should be renamed to different files.
>
> Currently, "suturing" is not supported, so we approximate it by
> dropping one file, and manually merging its content with the other
> file.

Hm.. isn't approximation by renaming simpler? That way, you'd just have 
to rename in any case and let the user solve the ncc later on.

> Renaming is currently supported.
>
> To implement this cleanly, I'd like to add support for these two
> resolutions in 'merge'. See
> http://lists.gnu.org/archive/html/monotone-devel/2008-04/msg00084.html
> for a little more discussion.
>
> This is also following up to the discussion in
> http://lists.gnu.org/archive/html/monotone-devel/2008-02/msg00141.html
>
> I can see how to allow merge to drop files; just call code from the
> 'drop' command.
>
> However, that appears to be quite a bit of detailed work. At a
> minimum, it requires preparing at least one more roster to allow
> commiting the drop before proceeding with the merge. So perhaps
> it would be better to implement file suturing now.

Yes, absolutely.

> I searched the mailing list archives for suturing. Nathaniel outlines
> the basic objection to it here:
>
> http://lists.gnu.org/archive/html/monotone-devel/2005-05/msg00326.html
>
> The problem use case is:
>
>        A   B
>       / \ /|
>      |   X |
>      |  / \|
>      | C   D
>      |/
>      E
>
>     Suppose A has "add foo", B has "add foo", D is a simple merge, so
>     D contains a single sutured file name "foo". Suppose also that C
>     has "rename foo bar", and E is a simple merge, so E has two files
>     "foo" and "bar".
>
> In pratice, what this means is one developer has decided to resolve
> the conflict via renames (deciding the files should be separate),
> while another developer has decided to suture the files (deciding they
> should be the same). Clearly one of these approaches is simply wrong,
> and should be reverted.

That problem would easily disappear if you rename in all cases.

If you absolutely want to offer the developer a choice in such 
situations, it might be better to rename first, then drop. That way, 
you'd have the actions separate, and if two developers decide 
differently, that results in yet another ncc we can hopefully.


Have you considered what happens, if two developers both decide on 
merging the files, but a different node-id is choosen? As node ids are 
local only, I think you cannot prevent that easily (i.e. by choosing the 
lower node id - those might be different - you'd have to compare birth 
date of the files. And even then, it might be possible they were born on 
exactly the same date...).

So, suppose A has "rename some to foo", B has "rename thing to foo" 
(just to use another ncc).  Dev 1 merges the files and decides to keep 
"foo" from rev A. Dev 2 also decides to merge, but decides to keep "foo" 
from rev B. If you then merge C and D, both node ids will disappear and 
the merged revision will lack file "foo". :-(

(A challenge for the file resurrection UI: what should mtn do, if the 
user then wants to resurrect file "foo" from the merged revision? There 
are two node ids which were named "foo".)

> There are similar problem cases where developers do bad things after a
> suture; they have similar resolutions (tell the developers not to do
> bad things :).

I'm not quite following here, but I guess that's dependent on the file 
suturing implementation, anyway.

> However, I don't see anything in the mailing list about how to actually
> implement suturing.

Well, AFAIK the plan is to add a liveliness attribute to the files. 
That's a simple boolean flag which gets merged with our normal merge 
algorithm.

Regards

Markus