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

[Markus Schiltknecht]

Hi,

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.

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.

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

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.

Uh.. but let's limit N to N = 2 for a start. I don't think we need to 
suture together more than two files at a time (i.e. in one revision).

> We currently don't have 
> (a) a mechanism to achieve that and (b) only a small clue of what problems 
> will arise afterwards. Don't let us confuse and/or intermix these two steps.

I'm not sying such a mixture here. I'm trying to find out what problems 
will arise with which approach. 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.

Regards

Markus