Julian Foad wrote:
> Daniel Shahaf wrote:
>> C. Michael Pilato wrote on Tue, Jul 24, 2012 at 21:31:49 -0400:
>>> For ra_svn: I was totally wrong. This thing always requires network
>>> activity: a "reparent" command/response at best; at worst, the complete
>>> teardown and re-opening of the session. This is just a side-effect of the
>>> stateful protocol. Unlike with HTTP, the server here is privy to the
>>> "session URL" concept -- clients only perform operations using relpaths
>>> against that URL -- and so the server must be told when that has changed.
>>
>> So... should we revv ra_svn so 1.8 clients/servers can talk to each
>> other exclusively in repos-root-relative paths?
>
> That sounds good to me, but I don't understand the authz impact.
>
> In much of the merge code, it is convenient to carry around just one RA
> session
> and reparent it as necessary to address (parts of) the source and target
> trees
> in the repository. I have been changing more of the code to work that way,
> and
> would like to continue.
>
> If we can alleviate any ra_svn performance impact by adjusting RA_svn, that
> would seem to be best.
To reduce the load on ra_sv, there's also a coding style change I could make.
In relatively low-level merge functions, instead of unconditionally reparenting
(temporarily) I could reparent only if the requested URL is not a child of the
current session URL.
Instead of
fetch_foo(url, session)
{
old_url = svn_ra_reparent(url)
result = foo(relpath="", session)
svn_ra_reparent(old_url)
}
change to
fetch_foo(url, session)
{
session_url = svn_ra_get_session_url(session)
old_url = NULL
if (! (relpath = svn_url_skip_ancestor(session_url, url)))
{
old_url = svn_ra_reparent(url)
relpath = ""
}
result = foo(relpath, session)
svn_ra_reparent(old_url)
}
- Julian
