Hyrum K Wright <hyrum.wri...@wandisco.com> writes: > On Sat, Mar 3, 2012 at 5:31 AM, <stef...@apache.org> wrote: >> Author: stefan2 >> Date: Sat Mar 3 11:31:17 2012 >> New Revision: 1296604 >> >> URL: http://svn.apache.org/viewvc?rev=1296604&view=rev >> Log: >> Certain operations, e.g. svn ls, will contain timestamp and author >> information from many different revisions. A list of all projects >> in the root of the wordpress repository will open, read and close >>>75.000 revision property files (3 reads for each list entry) >> >> This commit implements revprop caching. It will be activated as >> part of the full-text caching option. >> >> Since revprops may be written by other threads or processes, we >> need to track the revprop changes. A new special file contains a >> counter that will be increased each time revision properties get >> rewritten. >> >> This counter is internally called "revprop generation" and will be >> read upon the first revprop access for given fs_t. Later changes >> may remain invisible for that fs_t. This behavior is in line with >> our revprop handling in other parts of FS_FS. If a revprop gets >> rewritten, the fs_t doing the write will use the new generation >> from that point on and will thus see all caches up to and including >> its own. >> >> Since the revprop generation becomes part of the cache key, each >> fs_t will only see revprops from its generation. It may also >> create new cache entries tagged with that generation, i.e. those >> would appear to be outdated for newer fs_t. But that will simply >> cause a benign false negative upon lookup. No fs_t will see >> data that got replaced before that fs_t was created. > > How does this potentially interact with revprop packing?
What about atomic revprop changes? I don't see what ensures that the old value read by change_rev_prop_body is the most up-to-date value. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
