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

[William Uther]

On 07/05/2008, at 10:08 PM, Markus Schiltknecht wrote:

> Thomas Moschny wrote:
> > Markus Schiltknecht wrote:
> > > You might even have renames, so that the file to be resurrected  
> > > isn't
> > > currently visible. How's the user supposed to resurrect the file  
> > > then?
> > Now I lost you ;) Resurrection is about bringing dead files back to  
> > live, so it will always be invisible before resurrecting it, no?
>
> Sorry, I wasn't too clear.
>
> My point was, that we are concentrating on node ids, but the user  
> doesn't have any way of referring to them. So it might not make  
> sense to concentrate on them.

Yes, there are two parts to this: behaviour and implementation.  We  
need to get both right.  By behaviour I mean something like UI - how  
would we like these features to work if we could implement anything.   
For implementation I'm referring to something that can be done  
efficiently, preferably without re-writing the whole current system.

> An example: how is bob expected to resurrect a file "foo", which got  
> overridden by another node id which is now called "foo". I can only  
> think of something like "take file 'foo' from rev '1234..' but name  
> it 'bar'", which will quite certainly make bob become crazybob.

That looks much like subversion's copy feature.  I think that would  
make merging hard for monotone.  It is a complete break with the  
current 'mark-merge' philosophy.

> > All three problems (resurrection, suturing, and copying) will need  
> > to establish some sort of connection between node identities in the  
> > graph (resurrection: 1->1, suturing: N->1, copying 1->N).

This isn't totally correct.  You need the node-id's you're talking  
about, but you also need the marks for mark-merge.  As has been noted  
by Thomas in another email, the problem with resurrection isn't with  
finding the node-id, it is with being able to get the marks when you  
later do the merge.  At the moment we don't keep the marks when we  
drop a file.

> Good line of thinking, that makes my point even clearer: we won't  
> need resurrection, once we have suturing and copying. Because 1->1  
> can easily be achieved by 1->N->1.

er, not necessarily.

It depends on whether dropping is seen as a separate thing to identity  
(in the copy-suture sense of identity) when doing a mark-merge.  There  
is also the issue that if N = 0, then you need to have a graveyard to  
hold the marks.  This whole 1->N notation is nice, but it is a  
simplification and doesn't catch all the details.

> And I'm currently concluding that the 'single bit aliveness flag per  
> node id' is overly complex for us and for the end user, while  
> suturing and copying might achieve pretty much the same effect.

A 'single bit aliveness flag' is a simple re-use of mark merge.  It  
will mean that aliveness has the same semantics as rename, move, and  
almost everything else that monotone merges.  This should be a good  
thing for using understandability.

Suturing is tricky.  We have no agreed mechanism for implementing it  
(yet).  And even if we did, none of the mechanisms I'm thinking of  
would, by themselves allow you to resurrect a file.  Suturing and  
resurrection interact, but they're not simple substitutes for each  
other.

Cheers,

Will         :-}