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@subversion.apache.org Subject: Re: [svnbench] Revision: 1447108 compiled Feb 18 2013, 00:21:45 on x86_64-unknown-linux-gnu Philip Martin <philip.mar...@wandisco.com> writes: > Neels Hofmeyr <ne...@elego.de> writes: > >> On Mon, 18 Feb 2013 00:55:07 +0000 >> ne...@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_tr...@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
