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

[Thomas Moschny]

Patrick Georgi wrote:
> Couldn't resurrection be done with a revision item like

It's not about how to encode the resurrection action, but about recording the 
fact that a node is dead in a revision, and where it was killed. The latter 
is the important thing. If you simply omit that information, then, if you 
merge that revision with another revision that _has_ the node, you don't know 
whether to keep it in the merged node or not. It could have been added or 
resurrected on the one side and deleted or simply not yet be born on the 
other side. We want to use our standard *-merge algorithm, which clearly 
indicates whether the node is to keep or not, based on (i) the scalar value 
('aliveness') on both sides and (ii) the markings for that scalar on both 
sides. (i) is easy (node is there or not), but (ii) is what we have to care 
about. 

In general, we decided to cache markings for the interesting scalars (path, 
content, and attribute changes as well as births) together with the actual 
values (path, content, attributes) for each node of the revision graph. That 
is what we call a roster. Again, it's a cache, and could completely be thrown 
away and reconstructed from the changesets.

The death markings ((ii) from above) can also be easily reconstructed, but 
this would impose a perfomance penalty. That's why we have to think about way 
of also caching that information, be it as part of the roster, or as a 
separate graveyard, or whatever.

> [...]
> but:
>
>   0     file a exists
>  / \
> 1   3   file a is changed (differently in both 1 and 3)
>
> 2   4   file a is deleted (both in 2 and 4)
>  \ /
>   5
>
>   6     file a is resurrected
>
> Which version should mtn resurrect? (it could ask the user, but we
> don't do that for other non-content issues, so what would be the
> default?)

This is the well-known problem of delayed content-conflicts arising on file 
resurrection. It *is* a content-conflict, and must be propagated to the user. 
In your example, there are only two changes conflicting, but you can easily 
imagine a case with N conflicts having suddenly to be solved.

Regards,
Thomas

signature.asc
Description: This is a digitally signed message part.