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.)
Have you considered storing your cache in the svn_client_context_t baton?
Does that allow the behavior you want without asking callers to do
svn_ra-ish stuff?
> Another thought: should part (or all) of the support for this kind of
> cache be provided by the svn_ra API rather than libsvn_client? Maybe
> with libsvn_client wrapping it in a libsvn_client presentation API.
I suppose this logic could live in the RA layer.
I haven't read the patch, but does it take into account that today, RA
sessions opened by client functions have differing sets of callback
functions implemented depending on how
svn_client__open_ra_session_internal() was called?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-09-14 22:02:08 CEST