[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
From: |
Thomas Moschny |
Subject: |
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: |
Wed, 7 May 2008 15:44:30 +0200 |
User-agent: |
KMail/1.9.9 |
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.
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, (continued)
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/08
- [Monotone-devel] Graveyards vs reconstruction for liveness merging (was: resolving name conflicts; file suturing vs drop), William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop,
Thomas Moschny <=
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/08
- [Monotone-devel] File resurrection, William Uther, 2008/05/08