On Fri, 9 Apr 2004, C. Michael Pilato wrote:
> We have two walks because the wc-props are a cache system, and bad
> stuff happens if the cache is wrong. So, we clear the cache
> (painstakingly) before the switch so we don't wind up with a race
> condition should something break during the switch. Then afterwards,
> the REPORT response gives us back all the new cache values, which we
> then write to disk.
Sounds reasonable, though in my mind, if the other access methods can get
by without this operation, it seems as though there should be a way for
ra_dav to do the same. What's inherently different about ra_dav that
gives it a race condition the others don't have?
> We could lose the second of these walks and amortize the cost of
> having no cache across the set of future operations (the first we
> needed the Version Resource URLs for a given path, we'd have to ask
> the server for it and cache it).
>
> We could probably speed up the first of the walks by just 'rm-ing' the
> wcprops files instead of reading and writing empty ones, though I'm
> just guessing at that (and don't know what kind of other pains that
> might cause).
Could svn just maintain the wcprops in the 'entries' file along with the
other attributes? There's a full tree entries read right before the first
wcprop walk, and then there's a full tree entries write after the second
wcprop walk. There doesn't appear to be anything special happening in
between either pair.
For my repository/hardware/configuration, the entries write step is only 7
seconds vs. the over 2 minutes it takes to manage all the individual small
files. Assuming the wcprops walks are entirely I/O bound, managing the
wcprops in the entries files would reduce the total time to approximately
20 seconds from over 4 minutes.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 10 06:29:31 2004