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.
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel