D.J. Heap wrote:
> Does that sound correct? File attributes and file permissions are
> distinct on Windows NTFS, but not really on Unix? And even though APR
> has separate functions to read/manipulate each, Subversion is kind of
> munging them together?
Yes, that is my impression as well. Also, note that if my two patches
get committed to APR, the INCOMPLETE messages will go away.
> It used to sort of work in old APRs because the calls to get security
> failed on Win32 (because the file wasn't opened with READ_CONTROL
> access) and so it called guess_protection_bits which just looks at the
> readonly file attribute and makes up some permissions based on that.
Correct.
> 6. I guess Subversion needs to be fixed to look at/change the
> readonly file attribute even if permissions are the same (in
> svn_io_set_file_read_write_carefully)?
I've just made some profiling on trunk on Win32, and these are my findings:
I have a repository with 5 directories, 3 tiers deep and 5 files in each
dir (created with stress.pl). In this I changed all the files to
svn:needs-lock to force a change in readonlyness, and to be able to see
how much the corrected APR inflicted upon Subversion.
(I previously made the same check on 1.30, but it seems that some of the
places that took lots of time are gone, I'll do a blame and see where
they went...)
So before the test I did up WC -r 1 to seed it with files without
readonly flag, and then profiled the call 'svn up WC'.
With a corrected APR and trunk, apr_stat took between 35% and 40% of the
total time used, only when *setting* the readonly flag. How serious in
the real world this is, I cannot say.
After I changed svn_io_set_file_read_write_carefully to be just
set/clear the readonly flag on Windows, apr_stat disappeared from the
"top" list (landing on 2% total time), being replaced by apr_file_rename
and apr_file_open (which seems reasonable).
>
> I hope that makes sense...
>
> DJ
I hope the above does too.
/Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 11 11:50:15 2006