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

[Markus Schiltknecht]

Hi,

William Uther wrote:
> > 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.

I was trying to say that it's hard for the user to specify which node id 
she wants to resurrect, in case its filename got reused by another node. 
 It's an argument against concentrating on node ids, and has not much 
to do with the implementation.

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

With suturing + copying, as I'm envisioning, we don't need to keep them.

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

I'm not following you here. IMO, 1->N is a generalization, which we 
don't need. 1->2 is absolutely enough, because we can simply repeat that 
to get 1->N (for N > 2).

We already have 1->0 and 0->1: that's simply add and drop.

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

..but a bad thing for content merges, which can get delayed - so one 
potentially needs to do multiple merges before having resurrected a 
file. And not to forget about the problem of having to keep the node ids 
forever.

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

I still disagree in that copying+suturing can be a replacement for 
resurrection (but certainly not the other way around). See my lengthy 
other mail in answer to Thomas, where I'm giving examples of how that 
might work.

Regards

Markus