> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: vrijdag 29 mei 2009 16:13
> To: Hyrum K. Wright
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Issue #3242 is heating up.
>
> 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.
I did an attempt on fixing this a few months ago. (I should have a dirty
patch somewhere).
Most operations are rooted on the common parent, but this was the same
before 1.5. But in 1.5 opening a RA session over http starts with an OPTION
request to the root where the ra session is rooted on. (I found a way to
work around this by retrying on a lower level and then reparenting).
But looking further I found a mergeinfo lookup issue. This merge info
request (after most other work is complete) explicitly roots the ra session
at the repository root. It could be that just resolving this specific
session reparenting resolves a big part of this issue.
> So... yeah. Nasty stuff.
Bert
>
> --
> 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=235
67
> 88
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2356791
Received on 2009-05-29 16:30:37 CEST