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

Re: svn commit: rev 4621 - in trunk/subversion: include libsvn_client clients/cmdline svnversion

From: <rooneg_at_electricjellyfish.net>
Date: 2003-01-30 02:54:45 CET

On Wednesday, January 29, 2003, at 08:50 PM, Philip Martin wrote:

 Garrett Rooney rooneg@electricjellyfish.net writes:

 Eek. This code is *inside* libsvn_client. Our typical pattern is
 that a
 structure is opaque outside the library, but completely visible
 inside the library. Thus, we don't need to use getters/setters
 within the
 library. The code can simply refer to ctx-auth_baton.

 i could go either way on this. keeping it opaque seemed like a
 reasonable idea so that we could easily add new things to it in the
 future (post-1.0) while still remaining binary compatability, but
 realistically, if we're adding new callbacks or something keeping
 binary compatability might be pointless if we're breaking semantic
 compatability.

 Binary compatability isn't really important here, but there is another
 reason why you may want to keep it opaque and that's if anything gets
 cached in the structure. For example, the svn_wc_adm_access_t access
 baton is opaque to libsvn_wc, it caches the entries file and the
 interface is responsible for maintaining the cache. Of course the
 structure doesn't have to be opaque for you to do this, but being
 opaque ensures that your caching mechanism cannot easily be bypassed.

the only thing i've thought of caching in the context object is
possibly the parsed config files, so we can avoid reparsing them every
time we need a config option. do people think this is worthwhile? one
issue with this is that we parse the config files in places other than
libsvn_client, so either we'd have to pass the context object down into
other libraries or we'd have to explicitly pass the config data we got
from the context object into the other libraries.

what do people think?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:24:57 2006

This is an archived mail posted to the Subversion Dev mailing list.