[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: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: |
Wed, 07 May 2008 14:09:14 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080227) |
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
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, (continued)
- 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, William Uther, 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, Matthew Nicholson, 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, 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 <=
- 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, 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