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