> -----Original Message-----
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: maandag 25 juni 2012 17:44
> To: Bert Huijben
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
> 
> On Mon, Jun 25, 2012 at 11:34 AM, Bert Huijben <b...@qqmail.nl> wrote:
> 
> >> markp...@tigris.org writes:
> >>
> >> > http://subversion.tigris.org/issues/show_bug.cgi?id=4176
> >>
> >> > I think we need to find a way to include this patch.  I would suggest
> >> > a new runtime configuration option or an environment variable.
> >> > Something like "Allow concurrent client access".
> >>
> >> There are problems with the patch.  One is that it is incompatible with
> >> the legacy access baton API, so an application using that API will need
> >> to have exclusive locking disabled.  Another problem is the current
> >> implementaion results long-lived SQLite handles so programs using the
> >> newer API run into problems if with multiple/long-lived contexts.
> >>
> >> 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.

I read (from the previous quote):
> >>  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 read that as a suggestion of adding opt-out behavior to 'svn', not opt-in.

        Bert

Reply via email to