Re: svn commit: rev 2470 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> 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 plan, to the extent that such a thing ever existed, was that I
would first pass a baton everywhere. Then I would move on to cacheing
and make everything use the cache. Once the baton is in place
changing every svn_wc_entry call is not that hard, it's not thousands
of calls, just a couple of hundred.

I envisaged the baton using lazy initialisation to populate the cache
the first time it was required, so that if for some baton instance the
cache was never required it would not get filled.

Using a separate cached interface may be easier in the short term, but
in the long term the code will be better if the cacheing happens
without such an interface. Then all the code, both existing and
future, will use the cache.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org