Mark Phippard <markphip_at_gmail.com> writes:
> On Mon, Jun 25, 2012 at 11:34 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>>> I think the solution is to default to non-exclusive locking and to allow
>>> an application to ask for exclusive locking. Then the command line
>>> client can be patched to ask for exclusive locking. And we provide a
>>> config option that allows the user to prevent the command line client
>>> for asking for exclusive locking so that anyone who relies on the
>>> existing 1.7 behaviour can still get it.
>>
>> I don't think this should be the default for any client.
>>
>> If we make it the default for 'svn' we can just start calling it Subversion
>> 2.0 as it breaks all the existing multi client behavior.
>>
>> I don't see a problem with adding a '--exclusive' option or something (or
>> adding it to the config usable via --config-option), or whatever but I don't
>> think we should make it default on any platform.
>
> No one has suggested it be the default. Philip said the opposite. I
> thought he was just suggesting we ought to create a way via our API
> for a client to ask for the behavior. We can then decide on what
> optional way to let the svn client ask for it makes the most sense,
> such as an --exclusive option or runtime config etc.
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.
Received on 2012-06-25 18:17:20 CEST