Re: [Monotone-devel] resolving name conflicts; implementation issues

[Stephen Leake]

Here's an approach to adding support for suture and split to existence
merge.

In a child revision with two parents, there are several cases:

        A1  B1
i)       \ /
          C1

    The node is merged in the child


        A1  B2
ii)      \ /
          C3

    The node is sutured in the child


        A1  B3
iii)     \ /
          C3

    The node was born in a suture or split in an uncommon ancestor of B

        A3  B1
         \ /
          C3

    The node was born in a suture or split in an uncommon ancestor of A


        A1  B
iv)      \ /
          C1

    The user created the node in A's uncommon ancestors

        A   B1
         \ /
          C1

    The user created the node in B's uncommon ancestors


        A1  B
v)       \ /
          C

    The node was deleted in B's uncommon ancestors

        A   B1
         \ /
          C

    The node was deleted in A's uncommon ancestors


In monotone 0.4 and earlier, cases ii and iii did not exist.

Case ii can only happen if we support sutures as user operations; I'm
not doing that yet.

To distinguish cases iii and iv, we need to store information about
how a node was born. This can be done in the marking map, by adding
birth_cause, a pair containing an enumeral and a pair of node_ids. The
enumeral indicates user, suture, or split; if suture, the node_ids
indicate the ancestors. If split, the first node_id indicates the
ancestor.

In case v, deletion wins over any other change; it might be better to
have deletion conflict with any other change. But that's left for
another time.

-- 
-- Stephe