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

[Thomas Moschny]

Markus Schiltknecht wrote: (graph kept for reference)
> Thomas Moschny wrote:
> >    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: ???
> > 
> > [...] 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.

There can, that's what suturing is about. It is the same thing happening in C, 
where we are suturing 1 and 2 both wanting 'foo' into 1&2. Why shouldn't that 
be possible again in F for 1 and 1&2 ?

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


You are cheating here. We don't have well defined nor understood semantics for 
copy yet. And by simply exchanging 3 for 1&2, or 4 for 1 and 5 for 2, you are 
pretty much hiding what we are (well, I am, at least) talking about: 

Establishing connections between different node identities. 

That is, a new node needs to able record the fact somewhere that it wants to  
inherit (or asymmetrically share) identity from (with) another node. I still 
have to think of what that actually means, though, especially for our merge 
algorithm, which certainly has to to be extended.

What I'm thinking of (implementation wise) is extending the birth record to be 
able to contain a list of 'ancestor' nodes, in terms of node paths in the 
respective parent revision. Note (a) that we don't have node_ids there, so 
nodes must be referenced by name, and (b) that we certainly don't want to 
allow nodes to be referenced in other revisions than in its direct parents. 
Otherwise we would create a new graph that can not be embedded in our 
revision graph, and my intuition says that would be a very bad thing (tm).

This would allow suturing and asymmetric copying, but not resurrection in the 
copy-sense, "hopping" over a whole part of the history. But that's fine 
anyway, because you can always commit a child revision of an old revision 
where the file in question was still alive and merge that with your current 
head, and that's the Monotone way of doing it.

Regards,
Thomas

signature.asc
Description: This is a digitally signed message part.