monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Schiltknecht
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Fri, 09 May 2008 13:16:58 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

Hi,

William Uther wrote:

On 08/05/2008, at 8:45 PM, Markus Schiltknecht wrote:


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


In the implementation of suturing in my head, node-id 3 is a synonym for "1&2". In this example, if you were to merge revs D and G, then node-id 2 from rev D should match with node-id 3 from rev G. The result is that the rename between B and D gets cleanly merged, and there is a three-way merge of contents between D and G with B as the ancestor.

Uh.. are you sure you mean B and D? There's no ncc between B and D, so those should clearly merge automatically, yes.

This automatic merging of changes to one of the files in a suture into the child of the suture seems to be one of the primary features of a suture.

Well, you are speaking about contents here. And I absolutely agree that contents should merge cleanly. I.e. for content merging, the merger will have to track down multiple node ids, yes.

Given that, I don't see how you get node I. In that case I would expect that node I would collect all the changes to node ids 1, 2 or 3. If you have DieDieDie merge, then the fact that you've killed node 1 would kill the other nodes?

It has killed node id 2. The difference is, that the merger will have to track contents across node ids, but not aliveness.

Or you could make suture conflict with rename and drop. In any case, I don't understand what happens at node I.

Node 2 got dropped due to suturing into 3 at rev. C. However, contents of node 3 come from nodes 1, 2 and 3. Just in a way that clearly prevents multiple stage content merges.

I'm also confused by what you mean by 'copy' in node K. There are two definitions of 'copy' floating around. One is the 'add a new node-id with the same contents as this other node' that you could currently implement with "mtn cat ; mtn add". That version of copy would not merge changes cleanly.

I'm thinking of this type of copying - an asymmetric one, where the user gets the file from the revision he requested. Not much unexpected magic.

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

I guess that depends on whether the deletion of node 2 between revs K and L causes the deletion of nodes 3 and 5 because they're all equivalent.

Huh? They are certainly not equivalent WRT aliveness. Node id 2 gets dropped there due to being sutured into 3 at rev. C - and no other operation is conflicting to that.

Revision L is a suturation of two files, for which - by my simplistic definition - the user has to do the content merging manually.

Hrm. If you have sutures conflict with deletes, then you're making the user choose what happens every time that comes up in a merge. You're relying on the fact that that wouldn't happen very often.

Correct. But besides resolving the 'same-file-added' non-content conflicts, which is the use case which inspired this proposal, I can't think of many other use cases for suturing. Can you?

A simpler way to achieve resurrection might be to have a "merge, but make liveness questions interactive". Any time a file is alive on one side of a merge, but dead on the other, then the user is asked whether to keep the file or not. If they decide to keep the file, then it is resurrected.

That does not help solving nccs or implement suturing, but yes...

This way, in normal use, die-die-die would remain. But if you want to resurrect a file, then you need to merge all heads with this interactive flag and decide to keep the node-id. Once you've merged all the so the remaining head has the node-id, the file is effectively resurrected.

Well, I think the problem basically is, that monotone currently prefers dropping over other actions. Maybe one could even argue about renaming or editing having to conflict with dropping, because those represent conflicting user intentions.

Regards

Markus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]