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

RE: Serious error in repository--help needed

From: Douglas Pearson <biz_at_sunnyhome.org>
Date: 2007-07-09 05:56:46 CEST

That's very disappointing to learn that we're really sunk here. Anyone else
have any other ideas beyond a complete rollback of the repository and
presumably days of struggling to find all changes and get them back into the

As to the cause, the description on the "fsfsverify" page
http://www.szakmeister.net/blog/?page_id=16 (and the existence of that patch
tool, which BTW is a year and a half old) seem to describe our situation
pretty accurately. Committing a large set of changes (this revision is
about 40MB) through apache2 can lead to an invalid revision on disk. As I
say, we've seen that pattern several times, but only when working with large
commits and never consistently.

However, there's something different about this corruption than the earlier
ones as the fsfsverify script fails to correct this problem.

As to whether there should be recovery tools, well frankly that seems like a
no-brainer to me. If SVN can cause corruption under normal usage (not some
weird power outage or disk failure case here--just a normal commit) then it
should be able to recover from those corruptions. It may be the error is
inside Apache, but even if that's true SVN needs to be able to get back to a
working state.


-----Original Message-----
From: Talden [mailto:talden@gmail.com]
Sent: Saturday, July 07, 2007 5:34 PM
To: Douglas Pearson
Cc: users@subversion.tigris.org
Subject: Re: Serious error in repository--help needed

Currently, yes, due to a lack of recovery tools there is no way to scrap
revisions newer than the first corrupted revision for recoverable content.

This issue has been discussed recently and opinion is divided as to whether
Subversion should provide recovery. This seems a glaring example of why
recovery should be provided. Sometimes you don't know corruption has
occurred until potentially hundreds of developer hours have been spent on
subsequent commits.

Finding out why the corruption occurred is as important of course, otherwise
a repeat performance can occur.

On 7/7/07, Douglas Pearson <biz@sunnyhome.org> wrote:
> We seem to have a corrupted revision in our repository.  When doing a 
> dump this particular revision gives the error:
> "Checksum mismatch while reading representation:..."
> We've seen similar errors to this in the past and the "fsfsverify" 
> script seems to have always fixed the problem but no luck this time.  
> Running that script leaves this revision unchanged.
> Can anyone help us recover our repository?
> Is there some way I can "zero out" that revision and re-commit the 
> changes that were made in it?
> Do we have to throw away the last few days of work and restore an 
> earlier backup and then re-commit everything since then (it'll be very 
> painful for us to do this).
> Doug
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 9 05:57:17 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.