Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800: > On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf <danie...@elego.de> wrote: > > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800: > >> I have had a developer here create a build of the latest SVN code > >> with your changes you mentioned in r1294470 for the svnadmin verify > > > > Okay, that's great news, for two reasons: > > > > 1. It means building svn on windows isn't as painful as it used to be :) > > Actually, it did take some work to get it going as we did not have > another system available to us and also did not have VC++ 6. We had > to use VS 2010 in order to do this. Also, for the other components > required (python,perl etc), the files after the install were copied > to the workstation to see if it would work as we did not want to > change the current workstation configuration by running the > installers. All in all, it did seem to work. >
Okay. The normal build requires just the *.exe and *.dll files to be placed appropriately (such that the *.exe's and httpd's find their libsvn_* DLL's at runtime) --- it doesn't require Administrator access, for example. To clarify, Perl is only required to build OpenSSL; it is not required to build APR, Neon, or Subversion. > > > > 2. It means I can ask you to build a custom server with the 'inprocess' > > cache disabled, or (if all else fails) to bisect, per my previous email. > > > > One of the things you could try is to disable caching: simply modify > > the function create_cache() in libsvn_fs_fs/caching.c to always return > > NULL in *CACHE_P. See below for another suggestion. > > > >> command. We have run 'svnadmin verify' against every revision of our > >> hotcopy of our repository taken when we first brought this issue to > >> the forums and are now tracking down each of the revisions to see > >> what actions were being done at those times. > >> > > > > Thanks! I do hope this work enables us to pinpoint and fix the bug. > > I will be going through the list to see what else was happening at the > same time on the apache server since it was alluded to that there may > be concurrency issues. I know the last two times that this error has > popped up, we had two svn operations starting at around the same time > according to the Apache logs. I will go through the previous apache > history to see if this was always the case or not. > Thanks, looking forward to hear what you come up with. FWIW, Justin's reply suggests that the error was seen on three different platforms --- Windows, Solaris, and FreeBSD --- so that should narrow down the range of possible explanations. (I'll also note that at ASF's installation we are not running into new instances of the bug.)