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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
