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