On Sunday 05 February 2006 10:55, Marc Sherman wrote:
> John Szakmeister wrote:
> > If you have the original repository handy, this is actually very easy
> > to fix. You can send me a private email if you need that done, but it
> > looks like you've already gotten back up and running using a
> > different solution.
>
> John, do you or Malcome have a tool (or instructions) for repairing
> these corrupted repositories that's publicly available? I've been
> living in fear of this bug hitting the repositories I manage at work for
> months now. :)
Have no fear. It's at least possible to recover with no data loss (at least
that's what I've experienced with the ones that I have personally fixed...
after I found the magic recipe).
I've attached my script. Your probing motivated me to automate the fix of
this problem. :-)
*** DISCLAIMER ***
THERE IS NO WARRANTY PROVIDED. USE AT YOUR OWN RISK!
I originally developed this tool to help locate the problem and examine some
of the metadata surrounding it so that I didn't have to look at a user's
proprietary data. It was never geared toward fixing this problem, and it was
never meant to be a real application of any sort. It's a complete hack.
However, I've used this on several bad rev files and it has successfully
restored them to full health.
First, make a backup of your repository! The tool is meant to be run against
the bad rev file. Running 'fsfsverify <rev-file>' will attempt to verify the
contents and notify you of the problem. It dumps a ton of other
information... that's normal. To try and fix the file, run 'fsfsverify -f
<rev-file>'. It runs through the same process as the previous command, but
this time it catch the error and attempt to fix the problem. It *will*
modify the rev file, so it's very important that you keep a backup copy of
the file. After everything is fixed, you should do a dump and load of the
repository to remove the extra cruft that's in there. If you don't care
about it, make sure to at least run 'svnadmin verify' to make sure everything
is okay. On that note, let me just say once again, that *everyone* should be
running 'svnadmin verify' or 'svnadmin dump' as part of a backup process to
verify the integrity of their repository.
If you still have a problem afterwards, contact me. I may be able to fix it,
if I have access to the repository.
> Also, what's the current timeline for fixing this problem in subversion?
> Is it expected to go into a 1.3.x release, or will it have to wait for
> 1.4.0?
Honestly, I don't know. I'm sorry to say that my time for Subversion has been
very limited lately. :-( I believe mod_dav_svn is the source of the problem
in that it's somehow opening two handles to the rev file. Unfortunately,
this problem is so intermittent, that I've been unable to reproduce it.
Malcome has proposed some changes to the FSFS backend that would prevent two
handles from being opened, but I'm not sure there was consensus on them. At
this point we aren't certain which line of code is in error, so it's hard to
say when a proper fix will be available.
I will say that 1.4.0 will introduce a new svndiff algorithm. Repositories
created with it will not verify correctly with this script. At this time, I
don't plan on updating the script unless I run into the problem, or I see
enough corruptions to motivate me to do it. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 8 11:32:10 2006