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

Re: [PATCH] Speed up client by re-using RA session connections

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 14 Sep 2011 22:13:32 +0200

On 14.09.2011 22:01, C. Michael Pilato wrote:
> On 09/14/2011 02:04 PM, Julian Foad wrote:
>> In the "status" API, in this patch, it appears that two separate
>> connections are wanted at the same time. That may not be necessary
>> there, and if the code can be rearranged to do the "get locks" before or
>> after the main work on a single connection then great, that's an
>> independent improvement; but for now let's ignore that possibility and
>> assume that in some cases like this we do need two parallel sessions.
>> The way I've handled this is to make the *caller* pass in two separate
>> caches, but that's ugly, exposing an implementation detail. A better
>> way would be for the code to "check out" two separate sessions from the
>> same cache.
>
> Ugh. No svn_client.h public function should need to an ra_session_t or
> cache thereof. Client operations at this level are designed to be
> self-contained enough to not require that every single individual client
> program manage such a low-level concept as a RA session. (And if there are
> API functions which fail that design tenet, we should try to understand why
> and remedy that problem directly.)

I'd like to point out that in TSVN, we use svn_client_open_ra_session()
to get an ra_session_t in some places. We use it mostly to call
svn_ra_get_latest_revnum() and svn_ra_get_repos_root2() in the same
session. And in two other places we call svn_ra_get_uuid2() and
svn_ra_get_locks2() (not in the same session).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2011-09-14 22:14:09 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.