[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1326354 - in /subversion/trunk/subversion: include/private/svn_named_atomic.h libsvn_fs_fs/fs_fs.c libsvn_subr/svn_named_atomic.c

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sun, 15 Apr 2012 17:40:14 +0200

Am 15.04.2012 17:02, schrieb Blair Zajac:
> On 04/15/2012 07:49 AM, stefan2_at_apache.org wrote:
>> Author: stefan2
>> Date: Sun Apr 15 14:49:21 2012
>> New Revision: 1326354
>>
>> URL: http://svn.apache.org/viewvc?rev=1326354&view=rev
>> Log:
>> Disable the revprop cache if our sync. mechanisms are too expensive.
>>
>> * subversion/include/private/svn_named_atomic.h
>> (svn_named_atomic__is_efficient): declare new API function
>> * subversion/libsvn_subr/svn_named_atomic.c
>> (SYNCHRONIZE_IS_FAST): new constant, set depending on system /
>> compiler capabilities
>> (svn_named_atomic__is_efficient): implement new API function
>> * subversion/libsvn_fs_fs/fs_fs.c
>> (has_revprop_cache): disable cache if sync is slow
>>
>> Modified:
>> subversion/trunk/subversion/include/private/svn_named_atomic.h
>> subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
>> subversion/trunk/subversion/libsvn_subr/svn_named_atomic.c
>>
>
>> +/** Returns #TRUE on platforms that don't need expensive
>> synchronization
>> + * objects to serialize access to named atomics. If this returns
>> #FALSE,
>> + * reading from or modifying a #svn_named_atomic__t may be as expensive
>> + * as a file system operation.
>
> That is assuming it's a local file system? It still may be faster
> than getting a file from NFS, which people will host repositories on.
>
The current implementation has a number of limitations:

* the repository must only be written to by 1.8+ servers
* revprop caching must be enabled on all of them or none
* all 1.8 servers accessing the repository must reside on
   the same machine
* the machine / compiler should provide fast low-level
   synchronization mechanisms

For the time being, I think these are acceptable because
those admins that care enough about the the possible
reduction in I/O will also understand its limitations.

Revprop packing will only be efficient with some sort of
caching mechanism to avoid re-reading large-ish files
over and over again. On the other hand, it may open the
door to less restrictive update checks once we've got a
format bump anyway.

-- Stefan^2.
Received on 2012-04-15 19:40:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.