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

[Thomas Moschny]

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.