"Bert Huijben" <bert_at_qqmail.nl> writes:
>> + This blocks every other application from accessing our wc.db at the same
>> + time as this process. So instead of using the working copy lock functions
>> + as designed other processes will already block before being able to check
>> + that the working copy is locked and without a way to report what blocks
>> + it or being able to recover using 'svn cleanup' when a process gets stuck
>> +
>> + BH: I call this a breaking change, but let's discuss that on dev_at_s.a.o.
>> + first. This behavior should be opt-in, not opt-out until 2.0.
The original discussion before the commit:
http://svn.haxx.se/dev/archive-2012-02/index.shtml#522
The second discussion after the commit:
http://svn.haxx.se/dev/archive-2012-10/index.shtml#365
>> +
>> ##########################################################
>> ###############
>> + */
>> if (!sqlite_exclusive)
>> svn_config_set(cfg_config,
>> SVN_CONFIG_SECTION_WORKING_COPY,
>
> If I would use 1.8 to run
>
> svn diff |more
>
> And leave that open in a console I would block TortoiseSVN, AnkhSVN,
> Subclipse, etc on my entire working copy, while this command doesn't
> even obtain a working copy lock.
>
> And as a developer on both 'svn' and AnkhSVN I often use 'svn diff'
> just for reviews.
Users that mix the command line with GUIs can switch off exclusive
locking. If we switch the default then users that want performance need
to switch on exclusive locking. I don't know which group is bigger,
users who want performance or users who want to mix clients.
> And all those other clients would just hang without a way to
> recover... or fail with some sqlite error that they can't convert in
> something which they can translate to 'some stupid user exlusively
> locked the working copy by touching it with svn'
>
> We designed working copy locks in our api to take care of the use
> cases where a client really needs to block out other clients on a part
> of the working copy, but we don't need them any more unless we revert
> this default change.
>
> Maybe it gives a nice performance boost, but I don't think this should
> be the new default for 'svn'.
Exclusive locking is the only way I know to fix the performance
regression on network disks that was introduced in 1.7 and is reduced
but still present in 1.8.
Subversion has always been slow on network disks but 1.7 was bad enough
to make large working copies unusable. Commit is a particular problem
because the way it scales is worse than linear with working copy size.
Taking a working with 12 copies of Subversion trunk:
1.6
status: 34s
commit: 32s
1.7
status: 45s
commit: 10m29s
1.8 shared locking
status: 50s
commit: 51s
1.8 exclusive locking
status: 17s
commit: 17s
I'm running these tests with a hot OS disk cache on the server but there
is additional caching in the NFS layer. The NFS cache appears to have
some sort of timeout so repeating a run soon after the first run
improves the speed (the server is otherwise idle). The difference can
be considerable for the shorter runs, 1.8 exclusive locking 3x faster at
about 5s, but is less significant from the longer runs.
It's clear 1.8 has made major improvements in commit performance: if I
double the working copy size I see commit times that double so your work
on commit has probably fixed the scaling issue. However 1.8 without
exclusive locking is still slower than 1.6.
In your other mail you wrote:
> 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.
This would only happen if such a client chose to both call the old APIs
and to explicitly enable exclusive locking. I don't know why a client
would do that. A client that simply continues to use the 1.6 API won't
have this problem.
> Let's call 1.8, Subversion 2.0 if we start breaking things this way.
Performance regressions also break things; 1.7 was bad enough to prevent
some users upgrading.
If we make shared locking the default can we make exclusive locking an
option? Suppose we had
[working-copy]
exclusive-locking = false
exclusive-locking-clients =
Where exclusive-locking is a global setting that the user doesn't
usually set, and exclusive-locking-clients is list of client names that
have chosen to allow exclusive locking to be enabled. The user sets
exclusive-locking-clients = svn
and the svn client recognises its own name at runtime and overrides
the global exclusive-locking setting.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2013-02-19 11:57:34 CET