> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 18 februari 2013 17:01
> 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
>
> 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.
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).
It even breaks the old access baton apis within a single client as they
sometimes need to open the same db multiple times to just detect that they
are the same db.
Let's call 1.8, Subversion 2.0 if we start breaking things this way.
Bert
Received on 2013-02-18 21:52:35 CET
