Ok, this is not going to fix every corruption that you might experience, but we have a small private SVN repository running on a Windows box that recently hung during a nightly backup using hot-backup.py a Python script we found out on the net.
I immediately ran svnadmin verify C:\svnrepos and found that revision #29 would not verify. I thought this strange, since we're up to revision 2093, and we've had clean verifications up until now.
Then, I immediately ran svnadmin dump C:\svnrepos > D:\svndump-2093.dmp to backup the repository, even if it was in a corrupted state.
Hoping for magic, I reran the verify, but no suprise- it still failed at revision #29.
I wasn't too worried, because we do a hotcopy backup every night, so could go back to a copy and only lose a few revisions, but nobody likes to lose data if it can be avoided. Plus, nobody likes to restore something as critical as an SVN respository unless it is absolutely necessary... or that is just me. :-)
Given that I was already looking at a restore, I figured I'd try the "default" troubleshooting techniques...
I rebooted. No change. Was worth a shot. Fixes more problems than it should on Windows...
Reading about the hotcopy back when we set it up, I learned there are transaction log files that it purges following a successful backup. Since the backup itself hung, I decided to try initiating another hotcopy backup, hoping some logfiles were in a corrupted state.
Bingo! Following that hotcopy backup, the svnadmin verify again ran clean! I immediately took another svnadmin dump for good measure, and went on about my business.
I hope this may help others avoid having to restore from a backup or (gasp!) get back up and running in the absence of a backup! (Say it ain't so, Joe!)
UPDATE: The same darned thing happened just a few days later, but this time the hotcopy backup did not resolve the issue. It was only after I had rebooted the box (an old P3 running Windows 2000 Small Business Server) that the corruption on verify magically vanished.
Still religiously snapping hotcopy backups, and recently have also started snapping svnadmin dump files as well... anticipating the corruption that does not go away on reboot.
BTW- The event log shows no problems reading or writing from the disks, so I don't think the hard disks are failing.