On Tue, Feb 19, 2013 at 12:45 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of >> Philip Martin >> Sent: maandag 18 februari 2013 17:01 >> 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 >> >> 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. > > Is the current default of 'svn' to be 100% exclusive on the working copy? > When a user not explicitly enabled concurrency > > So we block TortoiseSVN, Subclipse, AnkhSVN and all gui clients when running > svn? > > Is that our backwards compatibility guarantee where we worked on during 1.7? > > Any 'svn' accessing subversion blocking every other client 100% while they > are busy? > (E.g waiting for someone to resolve an interactive conflict). > > I'm +1 on making exclusive access configurable but 100% -1 on making it the > default behavior for any client especially 'svn'. > > This breaks any shared working copy and any system using multiple subversion > clients (Read: at least any of the 1 million+ TortoiseSVN + AnkhSVN + many > other client installs). > I completely agree with Bert: this change breaks Subversion for many scenarios.
-- Ivan Zhakov
