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

Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 08 Mar 2011 16:26:36 +0000

Stefan Sperling <stsp_at_elego.de> writes:

> On Tue, Mar 08, 2011 at 02:15:06PM +0000, Philip Martin wrote:
>> Stefan Sperling <stsp_at_elego.de> writes:
>>
>> > So I think it would be better if the cache was off by default, and must be
>> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
>> > configuration files would be the best location for this,
>>
>> svnserve doesn't have a configuration file. There is a per-repository
>> configuration file, but as I understand it the cache is a per-process
>> entity affecting all the repositories.
>
> Ah, true. We could make it a command-line option, then.

It's already there: -M (--memory-cache-size).

>> > because the
>> > purpose of the cache seems to be to speed up server operation.
>> > An 'svn' process has a short lifetime so the benefit of this cache
>> > seems dubious in that situation. I don't see any reason to even provide
>> > a way to turn it on there.
>>
>> I guess it depends on the access patterns caused by the operations, it
>> might well speed up merge/diff/blame over ra_local/FSFS.
>
> Fair enough, but it should still be opt-in.
> We could add a config directive in ~/.subversion/config.
> If it turns out to be beneficial, users will enable it.
> However, since ra_local is used mostly for testing I don't expect this
> to be used much in practice. Our test suite might benefit.

svnadmin also reads .subversion/config and also has a -M option. Which
leads to my original questions: should we use the config file to
configure svn, should we have a -M option for svn, should we use the
config file for svnadmin, should we use the -M option for svnadmin.

-- 
Philip
Received on 2011-03-08 17:27:11 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.