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.
Received on 2011-09-15 11:28:26 CEST