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

On 09/14/2011 04:13 PM, Stefan Küng wrote:
> 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).

My point wasn't to say "clients should be disallowed from using the RA layer
directly". Only that, by and large, the major version control client
operations should speak in terms of paths, URLs, and revisions -- not
low-level RA sessions.

Thinking of your use-case specifically, Stefan, would you benefit from a new
a client API function -- svn_client_get_repos_info() -- which fetches the
repository root URL, repository UUID, and (optionally) the current youngest
revision all in one fell swoop?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand