[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 07:48:16 +0200 |
User-agent: |
Mozilla-Thunderbird 2.0.0.12 (X11/20080420) |
Hi,
Thomas Moschny wrote:
A B
/ \ /|
| X |
| / \|
| C D
|/
E
Suppose A has "add foo", B has "add foo", D is a simple merge, so
D contains a single sutured file name "foo". Suppose also that C
has "rename foo bar", and E is a simple merge, so E has two files
"foo" and "bar".
Now, I merge E and D. What happens?
If D actually dropped both 'foo' nodes and created a new one 'foo' node with
merged content, merging D and E would be a clean merge: drop 'foo' from A and
drop 'bar' (being 'foo' from B), and add the new 'foo'. No conflict (with or
without DieDieDie, in that example).
Hm.. no, we cannot let drop merge cleanly with suturing. Because those
represent different user requests about how to proceed with a file.
(Where monotone should not have any preference).
Think of the following:
A B // both add "foo"
/ \ /|
/ X |
/| / \|
/ | C D // let D be the suturing of the "foo"s
F |/ // and (C, E) resolve the ncc with a drop
E //
// I only appended F, which is an edit
// of "foo"
Now, we have three heads. If droping doesn't conflict with suturing,
survival of the edit in F would depend on the merge ordering:
* if you merge E and F first, then D, the edit in F is lost.
* if you merge F and D first, then E, the edit in F is preserved
(though the content merge problem for suturing applies).
Being dependent on the order of merges is certainly a bad thing (tm).
(The other bad thing being, that monotone favors the suturing over the
drop).
Same applies for having a 'rename' in F. Thus suturing (as used to
resolve non-content conflicts) needs to conflict with dropping and renaming.
*Unless*, of course, we (after killing DieDieDie) decide that changing a
file's content or changing it's name causes it's aliveness state being marked
for the respective revision (in the sense of *-merge)[1].
Hm.. yeah, sounds reasonable.
In *that* case,
there would be aliveness conflicts (and probably also a chain of content
conflicts following) for old 'foo' and 'foo' aka 'bar' nodes, like Nathaniel
described.
Uh.. why does marking aliveness state influence the amount of content
conflicts?
But that probably shouldn't scare us anymore after we have learned
how to control resurrection and the content conflict chains arising there.
I've completely lost you here, sorry.
The problem is, that the all deleted files will have to stay in the rosters
forever. This is not so much a problem storage-wise, because we only store
leave rosters in full, and deltas for old rosters. Nevertheless it may have a
serious impact on speed as we still (at least temporarily) construct a lot of
full rosters for old revisions during common operations, e.g. pull.
Yeah, I'm aware of that problem. However, I don't think suturing (nor
copying) has much to do with file resurrection.
That's why I am still thinking we need a new storage scheme that allows easily
access to relevant parts of a roster - as we already do for restricted log
and annotate, but in a cleaner fashion.
Hm.. you mean splitting the aliveness information from rosters, as we
have split height information? Or what do you have in mind?
Regards
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, 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, 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 <=
- 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, 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