Re: Updated Issue 209 - support drop/modified conflict (monotone)

On Fri, Jun 08, 2012 at 02:53:30PM +0200, Markus Wanner wrote:
> 
> 
> Sorry, that was too brief. I'll give an example:
> 
>     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.  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.

-- hendrik