Hyrum K. Wright wrote:
> In order to minimize ra accesses, the code looks for the common parent
> of the source and the destination, reparents the ra_session to that
> location, and then proceeds to act using at that the operational root.
> The problem arises when that common root isn't accessible (due to authz
> restrictions), so the copy or move errors out. I *think* the solution
> is something along the lines of "be more intelligent about reparenting
> the ra_session" up to and including "don't reparent". That's a
> first-order approximation of what the solution could be.
Your analysis is correct. The solution involves giving precedence to
correctness (don't access paths you don't absolutely need to access) over
performance.
"svn move" is hampered at the moment by the design-level requirement of
anchoring the operation at the deepest common parent of the source(s) and
destination(s), and possibly one level higher if one of the sources of the
move *is* that deepest common parent. But that's always been true of "svn
move".
"svn copy" request only access enough to check the existing of the copy
source(s), and access to the lowest common parent of the copy destination(s)
(though... I seem to recall that our API pretty much demands that in a
multi-source copy, all the destinations are siblings of the same single
directory).
Of course, --parents throws a wrench into this, as we now might have to move
our anchor point (in both the copy and move cases) up to deepest
already-existing parent of the anchor point we would otherwise have used if
--parents wasn't specified.
So... yeah. Nasty stuff.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2356788
Received on 2009-05-29 16:12:58 CEST