> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 25 juni 2012 18:17
> To: Mark Phippard
> Cc: Bert Huijben; dev_at_subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
>
> 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.
I think we could remove the check for workqueue items without side effects if we somehow can make the base-delete workqueue operation stop editing the database.
(This call is used from the update editor when deleting a complete subtree)
At that point the database should always be stable in every intermediate state between workqueue operations, so opening the database would just be safe all the time.
Even now, it would probably be safe as an existing svn_client_ctx_t could still have the database open anyway, when another process introduces workqueue items.
When we developed 1.7 we inserted the 1.6 style loggy operations in the workqueue, and in those cases opening the database was certainly not safe.
Bert
Received on 2012-06-25 18:30:29 CEST