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

[Matthew Nicholson]

William Uther wrote:
> On 07/05/2008, at 1:21 PM, Matthew Nicholson wrote:
>
> > William Uther wrote:
> >
> > > This third option would avoid the drops entirely.  It has the problem 
> > > that I don't know how to reverse it.  i.e. if you merge two node-ids 
> > > then you could never tease them apart again.  Hrm.  You could just 
> > > introduce a new node-id with the current contents, but you'd have 
> > > lost some of the details in the history.
> >
> > Reversal involves making two new node id's each with the sutured node 
> > as a parent.
>
> Not sure what you mean by 'parent' here.  If you mean 'parent' in the 
> revision parent sense, then that is confused - we're talking about 
> files, not revisions.  If you mean 'parent' in the union-find algorithm 
> sense then what you describe will not achieve a split - both new node 
> id's would end up having the same 'set' according to the algorithm and 
> you have achieved nothing but a slight slowdown.

I realize we are talking about files not revs.

> The only way I can imagine making a 'split' is the simple one of making 
> a new file with the current contents - think 'copy'.  Hrm, I guess you 
> could make it symmetric and create two new ids (kinda like two copies 
> and a drop), but I'm not sure that is an advance.

I believe this is what I just suggested.

> > History is preserved and the files are split again.  This of course is 
> > roughly equivalent to the copy/split operation I have seen floating 
> > around.
>
> This is a tricky problem.  e.g.
>
>    a   b
>     \ / \
>      c   d
>      |\ /|
>      | e |
>      |   |
>      f   |
>       \ /
>        g
>
> Lower case letters are revisions, not files.
>
> a and b each create a file 'foo'.  I'll refer to them as fooa and foob.
> c sutures the two foos together - making fooc.
> d edits foob.
> e merges the changes made in d to foob into fooc.
> f splits fooc into ??
> g merges d and f.  What happens to the changes to foob in rev d?  Are 
> they dropped?  Are they merged into both child nodes of fooc?  Only one 
> child node, and if so, which?
>
> No imagine another child revision of a that makes changes to fooa.  It 
> then gets merged with rev g.  What happens now?

So this sort of thing makes me want git's throw "history to the wind and 
worry about content" approach, but we can approximate that with fancy 
UI.  Basically you have another non-content conflict when g merges d and 
f.  In f you have split files, we will call them food and fooe, in d you 
have foob.  I don't know how monotone's merger works, but I imagine, 
when it is time to merge f and d, the merger looks at fooe and food and 
realized they have a common ancestor in foob.  The conflict happens 
because we don't know if we should merge foob with food and/or fooe or 
if we don't merge at all and just have a non content conflict (to be 
possibly resolved by suturing foob with fooe and/or food.

That is very confusing.  If we just treat these files as if they were 
revisions then what happens?  First we have to pick either fooe or food 
to suture foob with because foo has "two heads" (the heads being food 
and fooe (and foob really)).  Once we pick one, we have resolved the 
conflict, as the newly created foof will be a non conflicting file as 
will which ever "head" (food or fooe) remained.

I believe the right way to suture and copy/split[1] is to have node DAGs 
which you have partially described in your emails with your parent 
node/replacement node talk.

[1] (really copy and split are two different operations)

--
Matthew Nicholson
matt-land.com