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

On 14.09.2011 22:22, C. Michael Pilato wrote:
> 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?

Yes, that would of course help a lot!
And maybe svn_client_get_locks() which wraps svn_ra_get_locks2(). Then
we could get rid of using svn_ra_* completely.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net