Hyrum K Wright wrote on Sat, Mar 03, 2012 at 09:51:07 -0600: > 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? >
I believe the two features are orthogonal. > -Hyrum > > -- > > uberSVN: Apache Subversion Made Easy > http://www.uberSVN.com/
