[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: |
Tue, 6 May 2008 19:54:19 +0200 |
User-agent: |
KMail/1.9.9 |
On Tuesday 06 May 2008, Markus Schiltknecht wrote:
> To be symmetric, suturing will have to drop both source files and create
> a new destination node. Only that way you can resurrect any of the two
> files later on, for example.
> I'm thinking of suturing as an atomic "delete two, add one" operation.
Like that idea, and I think it would solve Nathaniel's problematic example:
> 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).
*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]. 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. But that probably shouldn't scare us anymore after we have learned
how to control resurrection and the content conflict chains arising there.
> Hm.. maybe you need to outline your graveyard concept a little better.
> Last I've heard about file resurrection, we should simply add a boolean
> flag for alive or dead. That hardly carries any extra information, but
> could be merged the same as other attributes.
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.
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.
Regards,
Thomas
[1] Which might be reasonable: When I do change a file's name or it's
contents, I'm surely making a statement that I want this file to be alive.
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, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop,
Thomas Moschny <=
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Patrick Georgi, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/06
- 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, 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