| Re: Moves in FSFS
From: Julian Foad <julianfoad_at_btopenworld.com>
 Date: Thu, 19 Sep 2013 14:58:43 +0100 (BST) 
Branko Čibej wrote:
 I meant on the branch...
 >>  So the repository in r40 looks like:
 ... but it will make the problem even clearer if we also do it on trunk at the same time, ending up with:
   r40:
 >> Now we query: for each path in 'branch' in r20, where is "it" 
 Although I'd *like* a more optimal solution, I acknowledge that talking about the cost may be distracting us from the semantics.  So forget I mentioned that.
 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".
 - Julian
 | 
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.