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_at_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_at_20 does not yet have its own copy-id, it shares it with trunk/B_at_20. I'm saying that if you try to specify an algorithm that traces the moves that lead from branch/B_at_20 to branch/D_at_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. brane_at_wandisco.com
Received on 2013-09-19 17:51:29 CEST