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)?
Received on 2012-02-22 13:31:00 CET