You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Markus Schaber <m....@3s-software.com> on 2011/09/15 10:41:58 UTC
Recursion / reentrancy in SVN 1.7
Hi,
In our SharpSVN-based software, we happened to have recursive calls to
GetStatus inside the progress notification handlers. This worked fine
using SVN 1.6, but now with SVN 1.7, some operations like Checkout throw
an Exception, due to the working copy database being locked.
Maybe our internal design is suboptimal in this case, and I've
successfully developed a workaround, so it is not critical.
But this still is a regression.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
AW: Recursion / reentrancy in SVN 1.7
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Bert,
Von: Bert Huijben [mailto:bert@qqmail.nl]
> > On Thu, Sep 15, 2011 at 10:41:58AM +0200, Markus Schaber wrote:
> > > Hi,
> > >
> > > In our SharpSVN-based software, we happened to have recursive
calls
> > > to GetStatus inside the progress notification handlers. This
worked
> > > fine using SVN 1.6, but now with SVN 1.7, some operations like
> > > Checkout throw an Exception, due to the working copy database
being
> > > locked.
> > >
> > > Maybe our internal design is suboptimal in this case, and I've
> > > successfully developed a workaround, so it is not critical.
> > >
> > > But this still is a regression.
> >
> > This is an sqlite limitation. We cannot do much about it without
> > taking a huge performance hit.
>
> No, it doesn't have to be a sqlite limitation, it could be a
difference
> between the old loggy code and how we handle the working queue now.
> If there are workingqueue operations we don't allow opening the
database at
> all, while we used to allow reading the entries for things like
status.
>
> What kind of error do you get?
> (The SharpSvn stacktrace isn't really interesting for the users on
this
> list, but the message that is part from the trace matches exactly what
you
> would get from svn)
The message is:
"Previous operation has not finished; run 'cleanup' if it was
interrupted"
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Recursion / reentrancy in SVN 1.7
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: donderdag 15 september 2011 11:28
> To: Markus Schaber
> Cc: users@subversion.apache.org
> Subject: Re: Recursion / reentrancy in SVN 1.7
>
> On Thu, Sep 15, 2011 at 10:41:58AM +0200, Markus Schaber wrote:
> > Hi,
> >
> > In our SharpSVN-based software, we happened to have recursive calls to
> > GetStatus inside the progress notification handlers. This worked fine
> > using SVN 1.6, but now with SVN 1.7, some operations like Checkout throw
> > an Exception, due to the working copy database being locked.
> >
> > Maybe our internal design is suboptimal in this case, and I've
> > successfully developed a workaround, so it is not critical.
> >
> > But this still is a regression.
>
> This is an sqlite limitation. We cannot do much about it without
> taking a huge performance hit.
No, it doesn't have to be a sqlite limitation, it could be a difference
between the old loggy code and how we handle the working queue now.
If there are workingqueue operations we don't allow opening the database at
all, while we used to allow reading the entries for things like status.
What kind of error do you get?
(The SharpSvn stacktrace isn't really interesting for the users on this
list, but the message that is part from the trace matches exactly what you
would get from svn)
Bert
Re: Recursion / reentrancy in SVN 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 15, 2011 at 10:41:58AM +0200, Markus Schaber wrote:
> Hi,
>
> In our SharpSVN-based software, we happened to have recursive calls to
> GetStatus inside the progress notification handlers. This worked fine
> using SVN 1.6, but now with SVN 1.7, some operations like Checkout throw
> an Exception, due to the working copy database being locked.
>
> Maybe our internal design is suboptimal in this case, and I've
> successfully developed a workaround, so it is not critical.
>
> But this still is a regression.
This is an sqlite limitation. We cannot do much about it without
taking a huge performance hit.
There was a long discussion about this a few months back:
http://svn.haxx.se/dev/archive-2010-11/0545.shtml
The discussion itself went on for several months, so be prepared
if you want to read all of it.
http://svn.haxx.se/dev/archive-2010-12/0278.shtml
http://svn.haxx.se/dev/archive-2011-01/0188.shtml
http://svn.haxx.se/dev/archive-2011-02/0048.shtml
Parts of this discussion were about providing separate code
paths for the legacy APIs. These wouldn't run into a locked database
but suffer bad performance. I don't think we ever got around to
implementing this workaround (we could still do so in a 1.7.x patch
release if necessary).
I am also not sure if our current set of API docs really reflect
what was discussed (the main focus at the time was to get the new
code to perform well).
I would suggest to think of the notification callback in the same
terms as an interrupt handler -- it gets some information when it is
invoked, and should either store this information somewhere or print it.
But it must return to its caller as quickly as possible to let the main
code get on with its task.