[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: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-07-11 22:18:33 CEST

On Thu, Jul 11, 2002 at 08:49:17PM +0100, Philip Martin wrote:
> 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.

And, there is my problem - 'couple of hundred' places. Ouch!
Every one of those places has to be completely rethought - most
of them are calling svn_wc_entries_read - that should no longer
occur. So, it isn't as simple as 'stick a baton parameter in.'
Perhaps it would make sense for us to branch off and slowly get the
new API in place? When we're satisfied, we can merge back in.
(Not that I know how to do a branch, but...)

> 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.

Yeah, that's what my patch was doing (and which is why entries.c
needs to know the structure of svn_wc_adm_access_t). The only thing
that we need to think more about is how to do read-locking. My
guess is to use two separate files - one for read and one for write
locks. The caveat here is that this has to work on NFS-based fs -
which means that we should just test/set an existance of a file
that has a reference count in it (or something like that).
However, we can suffice with exclusive write locks for now (even
for reading).

> 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.

I agree that it makes more sense in the long run. This is just
a really daunting task that I'm not sure that any of us have the
time to tackle completely. The key thing I think is that we need
to divide this task up into smaller pieces. But, the problem is
that once we change svn_wc_entry *every* caller has to change at
the same time. Urgh. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 22:19:00 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.