On Wed, Feb 22, 2012 at 1:25 AM, Philip Martin <philip.mar...@wandisco.com>wrote:
> Branko Čibej <br...@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)?
