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

Re: svnadmin: Malformed file

From: John Szakmeister <john_at_szakmeister.net>
Date: 2006-10-04 23:05:48 CEST

----- Johnathan Gifford <jgifford@wernervas.com> wrote:
> Our 'Malformed file' error was due to the repository_name/db/rev/xxxx
> file and repository_name/db/revprops/xxxx file were completely garbled.
> It looked like binary when displayed unlike understandable text for
> other revisions. Double check your rev and revprops file for revision
> 200. If it is somewhat legible, look for the fsfsverify.py tool that
> John Szakmeister has written. It might fix your problem. If it
> doesn't, I'll let you (and everyone else) if CollabNet fixes our
> revisions our repository.
> I think what is interesting about this problem, the repository still
> functions. Unless you dump your repository or run svnadmin verify by
> chance, you'll never know you have a problem. So the moral of the
> story, schedule svnadmin verify to run at least weekly, if not daily.

Or run it on every commit (you can put it in the post-commit and just check the revision that was committed).

> But just as important make sure you do an incremental dump of each
> revision committed and keep them for a certain amount of time so you can
> rebuild the repository if the svnadmin verify fails.

This is where running 'svnadmin verify' on every commit would be beneficial. The problem is that the data is being corrupted as part of the commit process. So the commit succeeds without error, despite the fact that the data just became corrupted. Having it in the post-commit would allow you to throw an error back to the user and do something like send an email, so that an administrator can fix it ASAP.

Oh the other hand, Malcome just recently committed some code that implements some locking around the transactions, with the idea that another process won't be able to come and take over the transaction. This should prevent the corruption from occurring. I believe it's already been nominated for backport, so hopefully it won't be too much longer before that's released.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 4 23:06:32 2006

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.