On 19.09.2013 15:58, Julian Foad wrote: > The key point here is that there needs to be a *unique* solution for where > branch/B@20 has been moved to in r40. With copies, of course, there is not a > unique solution when we follow history forward because there can be multiple > copies, but following moves forward through history must produce a unique > path (at each revision). > > The specific difficulty is that branch/B@20 does not yet have its own > copy-id, it shares it with trunk/B@20. I'm saying that if you try to specify > an algorithm that traces the moves that lead from branch/B@20 to branch/D@40 > using just (node-id, copy-id), you will go looking at the parent directories > to see if there any copies involved, and if the nodes you're looking at are > lazy-copied, and in doing so you will calculate a derived attribute that is > equivalent to "node-line-id".
I still don't see how that's different from detecting copies, or detecting moves in the current copy+delete implementation. IIRC, most of the work there is done by scanning the "changes" table, and the algorithm is path-based, not node-id etc. based. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
