On Wed, Feb 22, 2012 at 7:30 AM, Simon Butler <smcbutler_at_gmail.com> wrote:
>
>
> On Wed, Feb 22, 2012 at 1:25 AM, Philip Martin <philip.martin_at_wandisco.com>
> wrote:
>>
>> 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.
>>
>
> We would also prefer exclusive locking in our workflow and it would be great
> if we could program-in this kind of optimization in the client. I'm guessing
> there will others like this so why not have an "optimize" of similar switch
> that can take a list of settings (including exclusive=t)?
Are you just saying you want the performance increase it brings? I am
having trouble understanding why anyone would WANT exclusive locking
independent of the performance gain.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-02-22 13:44:13 CET