On Wed, Feb 22, 2012 at 7:30 AM, Simon Butler <smcbut...@gmail.com> wrote: > > > 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)?
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/