[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: <brane_at_xbc.nu>
Date: 2003-01-30 20:55:24 CET

Garrett Rooney wrote:

 Branko Čibej wrote:

 Garrett Rooney wrote:

  

 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?
   

 Actually, we should parse the config files (or create the svn_config_t's
 some other way) in the _client_, not in libsvn_client. Our libraries
 should not parse the config files themselves, ever. It's the client's
 responsibility to donfigure the libraries, not the other way around.

 this makes sense to me. how about we have something like:

 void svn_client_ctx_set_config (svn_client_ctx_t *ctx, svn_config_t
 *config);

Sounds good; but you need at least two such functions, one for config
and one for servers. there'll be otehrs later on...

 and then pass the context object down wherever we need the config
 information? this does seem to justify moving the context object out
 of libsvn_client though... perhaps in libsvn_util? in any case,
 having the context store config info is on my list of things to do,
 after notification functions and log message functions.

No, I think the context object should stay in libsvn_client; it just
shouldn't be filled in there. Its contents can come from all sorts of
places (the already come from svn_auth, svn_config and IIRC svn_wc, and
that's O.K:).//

-- 
Brane Čibej   brane_at_xbc.nu   http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:26:08 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.