monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Schiltknecht
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Wed, 07 May 2008 18:48:27 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

Hi,

Thomas Moschny wrote:
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.

Hm.. okay, for our current UI that might be true.

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

Can you please be more specific? Which three versions of the same file are you referring to? I only see two: those in D and E.

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.

Oh, okay, I didn't realize that. Maybe because I'm not thinking in terms of aliveness state, yet. I'm still trying to avoid having to bite that bullet.

Regards

Markus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]