Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)

[Markus Wanner]

Hendrik,

On 06/11/2012 10:01 PM, Hendrik Boom wrote:
> On Fri, Jun 08, 2012 at 02:53:30PM +0200, Markus Wanner wrote:
>>
>>     A
>>    / \
>>  M1   D
>>   | \ |
>>   |   P    -- P is the "keep" resolution, effectively resurrecting
>>   |   |    -- the file and giving it a new node id.
>>   |   |
>>  M2   |    -- M2 and M3 are both modifications on the same file (but
>>   |   M3   -- now known under different node ids).
>>    \ /
>>     Q      -- Q merges. How?
>>
>> The issue you are facing in Q is that monotone thinks the two node ids
>> are distinct files. Even if you manage to teach it to "suture" because
>> the two files conflict by their path, figuring out what ancestor to use
>> is non-trivial. And certainly involves remembering the relation of the
>> file added in P to the one deleted in D (or modified in M1, same thing,
>> same node id).
> 
> What I've not managed to understand through this whole discussion is why 
> at P the file has to be given a new node id.

Resurrecting a file under the same node id pretty much leads to the idea
of tracking liveliness per file. It gets a tad harder than "just reusing
the same node id" because conflicts in the liveliness property of a node
id can arise. Consider the following case:

         A     -- has 'foo'
         |
         B     -- drops 'foo'
        / \
       C   D   -- both resurrect 'foo'
       |   |
       |   E   -- drop 'foo', again
        \ /
         F     -- is 'foo' dead or alive?

For the merge in F, neither the ancestor B nor the right side E have the
file 'foo'. However, it is in C. So under current (monotone-1.0) merge
logic, monotone would think C added the file and "keep" it in F.
However, I'd expect this to conflict, because the right side clearly
wanted the file dead, while the left side wants it alive.

Note that I'm personally not in favor of this approach, but rather
prefer implementing file resurrection via (asymmetric) copies
accompanied by sutures (which might well be harder to implement, yes).

Issues I know of with the liveliness tracking approach are: amount of
node ids grows infinitely (and any kind of of deferred cleanup
re-introduces the die-die-die issues).

And second, I'm not sure how content conflicts for dropped files can be
handled. After all, the file's contents must still be tracked in case
the file goes live, again. However, the user certainly doesn't want to
merge a dead file's contents. (OTOH content conflicts on dead files can
only ever arise if you propagate from two different branches, because
you obviously cannot modify a dead file directly).

> Why can't it have the one 
> it had at M1?  That's what it would have happened if it had been added 
> at M1 instead of being deleted at D.

Right, but if it had been added only at M1, the ancestor A (in the top
example) would not have the node id, either. That's how monotone
differentiates between added and dropped files.

Regards

Markus Wanner