On Tue, Feb 19, 2013 at 12:45 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----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).
>
I completely agree with Bert: this change breaks Subversion for many scenarios.
--
Ivan Zhakov
Received on 2013-02-18 22:22:35 CET
