RE: [svnbench] Revision: 1447108 compiled Feb 18 2013, 00:21:45

 on x86_64-unknown-linux-gnu
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hmm. I wouldn't expect libsvn client to affect a config that is managed
by applications and which might live for weeks in gui clients.

svn_client_context_t and svn_wc_config_t are typically used longer than
one command in any client but svn and these clients hand their config
instance.

Bert Huijben (Cell phone)
From: Philip Martin
Sent: 18-2-2013 18:21
To: Neels Hofmeyr
Cc: dev_at_subversion.apache.org
Subject: Re: [svnbench] Revision: 1447108 compiled Feb 18 2013,
00:21:45 on x86_64-unknown-linux-gnu
Philip Martin <philip.martin_at_wandisco.com> writes:

> Neels Hofmeyr <neels_at_elego.de> writes:
>
>> On Mon, 18 Feb 2013 00:55:07 +0000
>> neels_at_apache.org wrote:
>>
>>> Charts of this data are available at
>>> http://svn-qavm.apache.org/charts/
>>
>> Looking at
>>
>> http://svn-qavm.apache.org/charts/compare_1.7.0_trunk@last12.svg
>>
>> I notice that somewhere between r1439212 and r1441993, 'update' got a
>> lot slower. The dip is visible in evenly-spread and flat WCs, the very
>> deep WC test is not affected.
>
> This is caused by r1440008. The library now only looks at the SQLite
> exclusive locking flag when opening the wc_db, so when the client
> subsequently set the flag TRUE it has no effect.

I've fixed this with r1447378. Maybe this indicates an underlying
problem? Is it valid to tweak the config after creating the context and
expect the changes to be honoured? Should the context create functions
be making a deep copy of the config?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download