Branko Čibej <brane_at_apache.org> writes:
> On 20.02.2012 09:51, Markus Schaber wrote:
>> Hi,
>>
>> What about an "-exclusive" general option to the svn command line client, which triggers exclusive wc access for that specific command invocation / session?
>
> And you expect users to know when to use it, and especially when /not/
> to use it?
>
> Come now. Controlling performance tweaks from the user interface is
> hardly good design.
Not sure I agree, I don't see how anything other than the user can make
the choice.
The user has more information than the application can ever have. If
the user wants to be able to run two subtree updates in parallel then
exlusive locking must not be enabled. If the user wants to run status
during an update then exclusive locking must not be enabled. If the
user is happy with one process having exclusive access then exclusive
locking is a major performance gain. If the user isn't making that
decision how else can it be made?
The performance gains on NFS are large. I import Subversion trunk into
a repository to use as my dataset. I checkout, run status, modify a
single file, commit, run update. This is on my Linux-Linux NFS setup,
which isn't fast but has no other users.
without with
exclusive exclusive
checkout: 2m33s 53s
status cold: 3.6s 1.3s
status hot: 2.6s 0.4s
commit: 35s 3s
update: 4s 0.9s
It's hard to ignore performance gains that are so big.
We could completely rewrite the commit harvester to use queries more
suited to the single db. That might be faster but I don't know whether
it would it would get us the order of magnitude gain that exclusive
locking provides. It's a non-trivial amount of code.
I suppose we might be able to make status into a single query, but like
commit that's a major bit of code to be rewritten. It's certainly not
going to happen in 1.7, I suppose it might happen in 1.8.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-22 10:26:44 CET