Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf <danielsh_at_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.)
Received on 2012-03-02 17:13:14 CET