On Mon, Jun 25, 2012 at 12:16 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Yes. Locking would be disabled by default. Applications would request
> exclusive locking if they use the Subversion API in a manner that is
> compatible with such locking. The 1.8 command line client is
> compatible, the 1.7 client needs r1336442.
>
> At present multi-client behaviour is not perfect. If I run "svn status"
> while another process is running "svn update" or "svn commit" (something
> that takes a long time) then I sometimes see the working copy with
> status 'L' and I sometimes get an error message because a work-queue
> item is present.
>
> If the client enables exclusive locking then "svn status" would never
> show 'L' while the update is running, it would always show an error
> after first waiting for our SQLite timeout of 10 seconds. I suppose
> that is a regression but I expect few users of the command line client
> will care. A config option to force shared locking would restore the
> current 1.7 behaviour.
>
> I would probably giving the user a mechanism to ask for exclusive locking
> if the application does not request it.
I think of apps like TortoiseSVN which have a background process
monitoring working copies to maintain a status cache. These apps
could probably be updated to queue up these checks when they get a
database lock, but in the past they expected to be able to read the WC
even if the user was using the command line at the same time.
I still think having it as an option would be nice for users that want
to assert more control over how they are using the client and can get
the performance boost as a result.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-06-25 18:33:19 CEST