[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1365324 - reparenting an RA session each time it's used

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 24 Jul 2012 21:31:49 -0400

On 07/24/2012 06:50 PM, Julian Foad wrote:
> Bert I just tried to add that a reparent is not a 'free' operation... It is
> still an expensive operation compared to many other operations... But
> compared to opening a new ra session it is still at least 10 times faster.

I was curious about just how expensive reparent was. I naively expected it
was a simple string operation (assuming the repos root URL was cached in the
session baton). For others who were wondering, here's what I found.

For ra_local: I was right. String math only.

For ra_serf: I was right again. It's just a string operation when the
repos root URL is known. But I overestimated how common it was for this
value to be known. All HTTPv2 servers transmit the repos root URL when the
session is initialized via the OPTIONS command. For older servers, the
repos root URL is calculated and cached opportunistically as part of other
operations, but isn't strictly guaranteed to have been determined before any
particular reparent operation occurs. And when discovered in this fashion,
it's done using the very sort of PROPFIND dance that HTTPv2 was introduced
to eliminate. So yeah, potentially pretty costly.

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.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-07-25 03:32:27 CEST

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.