Re: svn commit: r1296604 - in /subversion/trunk/subversion/libsvn_fs_fs: caching.c fs.h fs_fs.c
Philip Martin <philip.martin_at_wandisco.com> writes:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>>> 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.
>> ffd->revprop_generation is used as part of the cache key, the file is
>> written before the write-lock is released and read again as soon as the
>> write-lock is taken. Do you see a problem?
> I'm worried about the case where the FS passed to
> svn_fs_fs__change_rev_prop has a cache that is already populated. The
> values in the cache might be out-of-date because some other thread with
> another FS has written newer values. It looks like change_rev_prop_body
> will examine the out-of-date cached value when doing the "atomic"
Maybe the threaded case is OK because there is only one cache? What
about another process that changes the repository after the cache has
uberSVN: Apache Subversion Made Easy
Received on 2012-03-05 12:28:09 CET
This is an archived mail posted to the Subversion Dev