[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moves in FSFS

From: Branko Čibej <brane_at_wandisco.com>
Date: Thu, 19 Sep 2013 17:50:53 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.