Re: repository corruption, many times

On 12/19/07, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
>
> Rick,
> After looking at your script, can you tell me a few things:
>
> 1) In svn_check_commit, why do you "verify" the current rev and rev -1?

That's leftover from when we were first trying to understand what was
happening. It wasn't clear when corruption was happening, so the script
checked the most recent two revisions on every commit. Now we now it's the
most recent commit that corrupts.

2) When svn_check_commit fails, can you tell me the exit number?

The exit value of *my* script will always be 0 unless it's called with no
arguments. However, if you're interested in the result of svnadmin dump....
see the next answer

3) Any chance you could get the error coming from Subversion?

[root@thebe subversion_BROKEN_r1297]# svnadmin dump --incremental -r 1297 .
> /dev/null
svnadmin: Decompression of svndiff data failed
[root@thebe subversion_BROKEN_r1297]# echo $?
1

We'll start there. At first glance, everything appears fine. I have
> a few ideas about concurrent access to "svnadmin dump" but we'll get
> there eventually.

It would be horribly ironic if the script that's checking for corruption is
the thing that's corrupting the repo.

And, now that you mention it, it *is* the case that this particular kind of
corruption (i.e., inexplicable, thus far) didn't show up until I put that
script in place to try to trap the previous kinds of corruption. I assumed
that svnadmin dump would be a read-only op and would therefore be safe even
with concurrent access.

Rick
Received on Thu Dec 20 00:29:22 2007