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

[Thomas Moschny]

Markus Schiltknecht wrote:
> Thomas Moschny wrote:
> > 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?

No, nothing wrong. This is a case however, our ui currently can't handle, 
because when merging D and E, possibly two conflicts have to be solved for 
the same file, because we have three versions to be merged into one.

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

Agreed.

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

Well, that was what njs' example was all about, and what I tried to explain 
(again) above. When merging D and E, you we have to suddenly merge three 
versions of the same file. This is what I call a "series with more than two 
content conflicts on the same file". 

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

No, I don't. I already said that I consider it reasonable to mark the 
aliveness state when changing, renaming, or maybe suturing nodes. The effect 
of this is that dropping in another branch would conflict with these 
operations, and thus I think I agree with you on that point, but simply 
expressed it differently.

- Thomas

signature.asc
Description: This is a digitally signed message part.