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.
