subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <philip.mar...@wandisco.com>
Subject Re: svn commit: r1296604 - in /subversion/trunk/subversion/libsvn_fs_fs: caching.c fs.h fs_fs.c
Date Mon, 05 Mar 2012 10:50:29 GMT
Hyrum K Wright <hyrum.wright@wandisco.com> writes:

> On Sat, Mar 3, 2012 at 5:31 AM,  <stefan2@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

Mime
View raw message