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

Re: The new svn_wc_adm_*_depth functions.

From: D.J. Heap <dj_at_shadyvale.net>
Date: 2004-03-11 02:44:32 CET

Philip Martin wrote:

> Jon Foster <jon@jon-foster.co.uk> writes:
>>>Index: subversion/libsvn_client/status.c
>>>--- subversion/libsvn_client/status.c (revision 8957)
>>>+++ subversion/libsvn_client/status.c (working copy)
>>>@@ -155,8 +155,8 @@
>>> /* Using pool cleanup to close it. This needs to be recursive so that
>>> auth data can be stored. */
>>> if (strlen (anchor) != strlen (path))
>>>- SVN_ERR (svn_wc_adm_open (&anchor_access, NULL, anchor,
>>>FALSE, - TRUE, pool));
>>>+ SVN_ERR (svn_wc_adm_open_depth (&anchor_access, NULL,
>>>anchor, FALSE, + -1, pool));
>>Does this *really* need to be recursive? The comment says so; I don't
>>know enough about the auth mechanism to be sure.
> The comment is out of date, it refers to an era when auth data was
> stored in the working copy. There may be other reasons why the
> recursive lock is required.

I also noticed a number of places that looked like they might not really
need a recursive lock. Once this patch (or some semblance of it) is
applied, I have a list I planned on looking at more closely in the near
future -- in particular the property stuff since it's performance is
another major annoyance on our large working copies where we use some
custom properties.

For this future optimizing, does someone know of a list somewhere of the
reasons why a full recursive lock is needed for operations that only
really use the immediate children of a directory? Such as the way the
auth info used to need it or other things like that? I haven't noticed
any such documentation, but I could have missed it.

I'm updating this patch (for Julian's comments) and will repost it later
tonight with a better subject.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 11 02:45:16 2004

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