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

[Markus Schiltknecht]

Hi,

Thomas Moschny wrote:
> Agreed, but in the example, this is not the case anyway. The only thing I said 
> was: *If* we implemented suturing as drop,drop,add (all within D), and not 
> cared about the relationships between the newly created file and its 
> predecessors, then there were no conflicts at all while merging D and E.
>
> *But*, I changed my mind, and now think that we must care about file identity 
> relationships. What we really want, is this: Pretend we could go back and 
> give both 'foo' nodes in A and B the very same node identity. The whole 
> monotone merging machinery would work as expected.

Correct, again, a good way to think of it.

> However, we simply can't do that. We can't go back and treat two different 
> file identities as a single one. Well, we can do it, locally, but only *as 
> soon as we know about the users wish to do so*. And the user in turn cares to 
> tell us only when ncc conflicts arise. And that's the point with Nathaniel's 
> example: D knows about the problem, but E does not, so in E we have two 
> nodes, and a delayed (=not yet resolved) content conflict popping up when we 
> merge D and E.

Correct. Anything wrong with that behaviour?

After all, D (the suturing) conflicts with C (the drop or rename), 
because those represent different user-chosen solutions to the ncc.

(E just defers the merge, but that's already possible now with simple 
renames.)

> Let me put it in other words: Killing DieDieDie and implementing suturing 
> properly will both yield merges where we are confronted with a series with 
> more than two content conflicts on the same file.

I've been concentrating on suturing, here. That one must conflict with 
drop and rename.

How do you expect to run into a "series with more than two content 
conflicts on the same file" given only suturing as an additional feature?

> > Yeah, I'm aware of that problem. However, I don't think suturing (nor
> > copying) has much to do with file resurrection.
>
> They do, see above.

You were still assuming nodes could change their aliveness state on one 
branch and be sutured on another branch and still merge cleanly.

But I'm saying that's not possible (nor wanted) and should yield an ncc. 
(See other mails for the reasoning). Thus preventing lots of trouble: it 
would allow us to implement suturing without worrying too much about 
aliveness of node ids.

> Rosters are caches carrying per-revision, per-node information (see my other 
> post), but are currently accessible per-revision only. All I'm saying is that 
> we should break this up and allow access to node-specific parts of a roster.

Aha, now I understand what you meant here, thanks.

Markus