Hi all,
The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it also provides a huge
performance boost when you use clients like TSVN
that fire a large number of "svn ls -v"-esque queries.
Since the FS API has no means to indicate that a
bunch of small-grained API calls actually belong to
some lager RA request, the revprop-gen file would
have to be checked on *every* revprop read. I.e.
the number of OS-level file operations is the same
as with reading the revprop file directly.
[Note to self: design FS2 such that all data access
is done in the context of query / transaction objects]
So, I made up my mind on how to solve the problem
and this is what I intend to do:
* undo the above-mentioned revs on /trunk
* open a branch and re-apply them
* introduce revprop caching as a third tuning option
next to "fulltext" and "deltas"
* introduce a new, private API that provides machine-
wide, named atomics (using the APR shared mem
API as a basis). Maybe, this will turn out to be useful
for other sync. issues in the future.
* use the that new svn__named_atomic API to
replace the revprop-gen file as well as the corresponding
member in fs_t, i.e. check the revprop gen before
*every* revprop read.
With that we could at least provide revprop caching
for repos that are accessed from a single machine
using only 1.8+ servers to write revprops. One would
assume that this is the case for must 1.8 users.
If all works out as intended, the changes will soon
be ready for /trunk.
-- Stefan^2.
Received on 2012-03-07 23:41:37 CET