On 29.09.2013 19:34, Stefan Fuhrmann wrote: > > On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej <br...@wandisco.com > <mailto:br...@wandisco.com>> wrote: > > > Exactly. And this is the second issue of the two I mentioned: in > order to make merge aware of moves, as opposed to copies, you have > to be able to detect that two distinct path@revision in fact refer > to the same branch of a node -- which is exactly the (node-id, > copy-id) pair, and that /is/ sufficient for the purpose. So again, > there's no need to invent another branch-tracking identifier. > > > Sigh. The (node,copy) pair *alone* cannot be sufficient to map > move sources and targets.
That's not the case I'm talking about. I believe we already came to the conclusion that, in FSFS, in order to answer the "what node got moved" question, we need help from the changes list. However I maintain that we don't need any extra info to answer the question, "are these two node revisions on the same branch." > In-depth reason: Once you accept that the move semantics as > suggested by Julian's definition is what you want to support, *any* > ID scheme must either be isomorphic to the node-line ID approach > or a true superset of it. In the latter case you must provide auxiliary > rules (can be implicit) that effectively limit the superset to the > original. > Otherwise, your implementation does not match the definition. As I said, this is a different issue. The jury's still out on whether I accept that definition of move semantics or not; but in any case, detecting moves and detecting sameness are different problems for different use cases. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
