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

[Markus Schiltknecht]

Hi,

Thomas Moschny wrote:
> Markus Schiltknecht wrote:
> > Can you please be more specific? Which three versions of the same file
> > are you referring to? I only see two [...]
>
> Ok, here's the graph again. But be warned, we need a lot of characters ;)
>
>    A: 1,foo,v   B: 2,foo,w
>     /\          /\
>    /  \        /  \
>   |    \______/____\
>   |          /     C: 1&2,foo,x
>   |         /        \
>   |        /          \
>   |       D: 2,bar,y   \
>   |______/              |
>   E: 1,foo,v            |
>    \ 2,bar,y            |
>     \___________________|
>                      F: ???
>
> It looks more complicated, but it isn't. I just added sort of a manifest to 
> each revision, with the following format: "REV: node_id,path,contents".

Thanks for that example, it will certainly help clarify things.

To keep things simple, I'm assuming suturing adds a normal node id, thus 
what you are denoting as '1&2' could really become node id 3. (Of course 
the extra information 'created from suturing 1 and 2' still has to be 
maintained).

> A and B create foo independently, with different contents. D renames the one 
> from B to bar and changes its content. E is a simple merge, no magic. It 
> contains both files, foo and bar with different contents. Now, in C suturing 
> takes place, denoted by the node_id '1&2' (whatever that means). In C also a 
> content merge took place.
>
> Now, consider F, merging E and C. How does its manifest look like?

Well, there's no way you can merge two revisions with an ncc, so there 
cannot be such a manifest in the first place.

Of course, we need to give the user a way to resolve that ncc again. So, 
to continue the above story, either the user decides that those should 
really be different files, then the continuation could look like:

      :             :
      E             C
      |             |
      |             G: -  # rev G drops 3 (i.e. the sutured 1&2) here
      H: 4,foo,v    /
       \ 5,bar,y   /      # rev H saves nodes 1 and 2 by
        \         /       # copying
         \       /
         F: 4,foo,v       # a clean merge now. 1 and 2 are gone due
            5,bar,y       # to the suturing into 3, which got then got
                          # dropped in G.


Or the user decides to keep them as one, that's slightly more 
complicated, because we also have to delete the sutured node, to get rid 
of the ncc:

     :             :
     E             C: 3,foo,x    # node id 3 is the sutured '1&2'
     |             |
     |             |             # rev G is saving node id 3 by
     |             G: 3,foo,x    # copying, thus creating node id 4.
     |             |  4,foo.cp,x
     |             |
     H: -          |             # H is dropping node ids 1 and 2 and
      \            K: 4,foo,x    # K drops '3' and renames node id 4
       \          /              # to the old filename "foo".
        \        /
         \      /
         F: 4,foo,x              # and again a simple and clean merge.


> I think there are two possibilities: "F: 1&2,foo,z" or "F: 1&2,bar,z". In both 
> cases, there are three contents to be merged: x, v, and y, and thus two 
> content conflicts to be solved.

If C and E are conflicting WRT node visibility, why care about merging 
contents? The user needs to resolve the ncc between A and B. If two 
users decide for different resolutions, namely C and E, they have to 
resolve that non-content conflict again, before caring about contents.

However, you may claim that having to drop one of the two sides isn't 
optimal, because it's potentially loosing information (i.e. there might 
be (content) edits we don't want to loose in both of the above 
continuations.

But then again, one can simply copy that file and suture it back again 
into the merged node id. A full example, starting from your sample:


    A: 1,foo,v   B: 2,foo,w
     /\          /\
    /  \        /  \
   |    \______/____\
   |          /     C: 3,foo,x           # Alice wants to suture the
   |         /        \                  # two files to resolve the
   |        /          \                 # ncc between A and B, but
   |       D: 2,bar,y   \                #
   |______/              |               # Bob renames one and then
   E: 1,foo,v            |               # merges into E
   |  2,bar,y            |               #
   |                     G: 3,foo,u      # both do some edits
   F: 1,foo,u            |               #
  /|  2,bar,y            |               # then Alice want to merge,
 / |                    /                # but figures there's another
/  H: 2,bar,y          /                 # ncc. She still thinks
|   \                 /                  # suturing is fine, thus
|    \               /                   # votes again for her
|     \             /                    # suturing approach, by
|      \           /                     # dropping the offending
|       \         /                      # node id 1.
|        \       /                       #
|        I: 3,foo,z                      # Resulting in dragging in
|            |                           # changes from node id 2,
|            |                           # but loosing other changes
|            |                           # to node id 1 from Bob.
|            |                           #
|            |                           # After a lengthy detabe with
|            |                           # Alice, he finally agrees on
|            |                           # suturing the files, but he
|            |                           # still want to keep his edit.
|            |                           #
K: 4,foo,u   |                           # So he copies his latest
 \ 2,bar,y   |                           # version of foo...
  \          /                           #
   \        /                            #
    \      /                             # ..and sutures that together
     \    /                              # with Alice's version, thus
     L: 5,foo,t                          # suturing 3 and 4 into 5.
                                         # (2 has been sutured into 3,
                                         # so it disappears).


This might or might not be easier to the end user, very much dependent 
on the UI and how much we polish it. However, it certainly prevents 
multi-stage content merging, while still giving a way to resurrect files 
*and* preventing endless growth of node ids required.

I might still be missing something, but IMO (asymmetric) copying 
together with suturing make for a pretty good file resurrection 
implementation.

Regards

Markus