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.