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.
