Re: proposing some other enhancements and a few questions

"Ich Selbst" <ichselbst@gmx.ch> writes:

> - the function getstatus seems to be very slow if

getstatus? Is this svn_wc_status to which you later refer?

> doing this for folders with many subfolders even if
> one only requests the status nonrecursive. Is it really
> vital to first lock the dirs before gathering the status?

Are you creating a recursive or non-recursive access baton? Are you
creating a read-only or a read-write access baton?

A non-recursive, read-only lock should not be expensive, as far as I
know, although there is an apr_stat() call. Recursive locks are more
expensive than non-recursive locks since they involve reading and
parsing the entries files. Write locks are more expensive than
read-only locks since they write to the physical filesystem.

> I don't know much about the internals though if it IS vital
> then just ignore me :)
> I'm complaining about this cause my shell integration
> makes the explorer react sluggy just to show icon overlays
> according to the subversion status...
> Or maybe I'm using the wrong function? I'm using svn_wc_status -
> is there a faster way to get only the text status of a single file?

That depends on what you mean by "text status".

However you do it, single-shot operations need to parse the entries
file. This is inevitably far more expensive than a single stat()
call. If the file's timestamp is later than the one recorded in the
entries file then svn_wc_status does a byte-for-byte comparison of the
file and it's text-base to determine if it is modified. If all you
want is an svn_wc_entry_t* then svn_wc_entry() is probably faster.

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