[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.20 release candidates up for testing/signing

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 20 Mar 2015 09:42:29 +0100

On Thu, Mar 19, 2015 at 7:42 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>> <TIME = 0.047000>
>> svn: E160004: Corrupt node-revision '0.0.r9/882'
>> svn: E160004: Missing id field in node-rev
> I don't see that on my Linux box. That's a complaint about the root
> node of r9, near the end of the file db/revs/0/0. On my Linux box the
> offset is 881 not 882, and the file ends:
> id: 0.0.r9/881
> type: dir
> pred: 0.0.r8/0
> count: 9
> text: 9 796 72 72 0bbc6c909be39d253813928a4611c161
> cpath: /
> copyroot: 0 /
> minfo-cnt: 1
> 0-1.0.t8-8 modify-dir false true /trunk
> 1-2.0.t8-8 modify-file true false /trunk/1
> 4-2.0.t8-8 modify-file true false /trunk/2
> 881 1018

Thanks for looking this up. Unfortunately, I can't verify the rev
file, since I don't have it anymore, it has been overwritten by trying
to reproduce it (grrrr, should remember to backup leftover
repositories and working copies after a failed test run, before trying
to reproduce it). Whatever I try now, I can't reproduce it anymore

On Fri, Mar 20, 2015 at 8:03 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, Mar 19, 2015 at 07:40:41PM +0100, Johan Corveleyn wrote:
>> Wait, did I say "reproducible"? Gah, I had it once, then reproduced it
>> shortly after (it's still in my scrollback history), then sent this
>> mail, and now I can't reproduce it anymore :-(. I've tried at least 20
>> more times ... This it not fun.
>> What has changed between the fails and now?
>> - Stopped Apache 2.4.12 which was still running (standalone, separate
>> console window).
> Hmm...
> Perhaps there was a corrupt revision contents cache that got flushed
> by restarting Apache?
> Otherwise, no idea.

Thanks for the suggestion, maybe something like that could be the
cause. Not exactly a corrupt cache in Apache (because the test failure
I had was with ra_svn), but perhaps a leftover corrupt repository on
disk, still being locked by apache or ... something like that.
Otherwise I don't see how an Apache process could interfere with an
svnserve process.

I do remember that, before I started the ra_svn tests, I did a short
attempt with ra_serf against that particular Apache process (which I
had just started then). That test run failed somewhere (because of a
known issue of AVG Surf Shield interfering with serf (issue #4175 --
fixed in 1.8 but never backported to 1.7)), and I aborted it (Ctrl-C).
After that I left Apache running, disabled AVG Surf Shield, and
started a batch script that ran ra_local, ra_svn, ra_neon and ra_serf
in sequence. So maybe, just maybe, that first aborted ra_serf run left
something broken on disk that was later hit by the ra_svn test run
(but not by the ra_local test run that ran first, and not by the
ra_neon and ra_serf test runs that came later ???).

Anyway, I'm going to leave it at that, and conclude this is some weird
one-time local issue. I'll retest ra_svn once more tonight, and if
successful I'll commit my signature tonight or tomorrow.

Received on 2015-03-20 09:44:47 CET

This is an archived mail posted to the Subversion Dev mailing list.