[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 2470 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client

From: mark benedetto king <bking_at_inquira.com>
Date: 2002-07-11 21:45:51 CEST

On Thu, Jul 11, 2002 at 12:34:55PM -0700, Justin Erenkrantz wrote:
> On Thu, Jul 11, 2002 at 02:10:44PM -0500, philip@tigris.org wrote:
> Okay, so here's the crux of the caching matter.
> We need to be passing the access baton into the svn_wc_entry
> functions. So, does it make sense to create a "cached" variant of
> svn_wc_entry that can take in the access baton (basically what my
> patch does)? We can then switch places over to use the cache where
> we have access to the baton.
> Or, does it make sense to try and modify every usage of svn_wc_entry
> to require an access baton? -- justin

My concern is that if we allow mixing these methods that the baton's cache
could get out-of-date.

A short-term solution (that violates all the coding standards) is to
build a static dir->entries-cache lookup, and just use that until we've
cleaned up libsvn_wc. Then the whole baton thing goes away. We'd get
all the advantages and only lose some elegance temporarily.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 21:51:05 2002

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.