views:

546

answers:

1

Regardless of how I got here, I'm in the position of restoring a SVN repository from backup. Unfortunately the backup was slightly corrupted and out of over 19000 revisions, approximately 80 are lost. The backup was a bzip2 file and I was able to use bzip2recover to recover about 99% of the blocks. These are 'known good' since they decompressed successfully.

Therefore I was able to create a list of known-good commits, and lost commits.

The original repository was also corrupted but many of the files survived. Unfortunately the repository as a whole is broken though.

So I am lucky enough to have the files from the original db/revs and db/revprops directories for these missing revisions. The odds are that the corruption of the backup bz2 file does not align with the corruption of the db/revs files.

I have rebuilt everything up to r13892, but I know that r13893 is corrupt so I don't have a dump for r13893. I do have the files db/revs/13893 and db/revprops/13893 from the original repository.

I created and rebuilt the repository with svn-1.4, but I upgraded to svn-1.6 so that I could use the selective svnadmin verify command (on a single or range of commits).

I thought perhaps I could drop in these two files into the new repository, update db/current [1] and then continue. However when I try to verify I get this error:

$ svnadmin verify new-svn
* Verified revision 1.
...
* Verified revision 13889.
* Verified revision 13890.
* Verified revision 13891.
* Verified revision 13892.
svnadmin: Can't read file 'svn/db/revs/13214': End of file found

So this obviously didn't work. Not sure what 13214 has to do with anything here.

I downgraded back to svn-1.4.6 just in case anything odd was happening with 1.6. Unfortunately I get the same result - revision 13893 is not verifying:

...
* Verified revision 13891.
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214':
End of file found

So here's what I know:

  • I know that revisions 1 to 13892 are 100% correct (unless by some extremely unlikely chance a bz2 block has decompressed incorrectly but passed checksum).
  • I do not know if the r13893 files from the original SVN repository are OK - they may be corrupt, but the amount of corruption was so small it's unlikely (but possible).

Does anyone have any ideas how I might be able to fill this hole? Note that I have a 100% confident r13894 in my possession, so if I can get r13893 plugged I can move on with the rest of the restore.

[1] I updated db/current with this script: http://svn.haxx.se/users/archive-2005-12/att-0630/make-current-fix.py

I tested this on some other SVN repositories (after disabling the write to db/current!) to verify that it was producing the same value as that already there. It does.

+1  A: 

Regarding this:

svnadmin: Can't read file 'svn/db/revs/13214': End of file found

I suspect that rev 13893 referenced something from rev 13214 (such as a file copy, or skip-rev stuff, or something).

When doing the svn load, did the new revisions match the original revisions? I recall running into a case where my dump referenced a rev 0, and it got loaded as a rev 1. If something like that is happening here, the back-reference to rev 13214 will be off by one.

You might try using the files from the repo db to create the missing rev in dump format. Unfortunately, I don't know of a tool that will do that. But I would recommend looking at SvnDumpTool; it is able to manipulate svn dumps in a lot of useful ways.

Disclosure: I have contributed to svndumptool in the past

retracile
Yes, at the top of r13893 it says:DELTA 13214 0 12567271So it's a delta on top of 13214, which explains where that comes from.One thing I notice is that my reconstructed binary commits (in db/revs) start with this:SVN^A^@^@<86><A0>^@Yet my original r13893 commit looks like this:SVN^@^@<86><A0>^@Note the first byte after "SVN" is ^@ (00) in the old commit, but ^A (01) in the new commits. Is this an xdelta version number? Perhaps I need to rebuild 1 to 13892 with a version of subversion that uses the same xdelta format?
meowsqueak
I don't know about the ^@ vs ^A. But when loading the dump, it should tell you what the original rev number was, and what the newly created rev number was. Do those two numbers match?
retracile
Yes, those numbers match.I solved this problem actually - it was because I'd created the new repo with 1.4, but the old files were created with 1.3, so the xdelta format was different. I started again with svn-1.3 and this problem is now solved.Unfortunately svnadmin segfaults later on, so all is not quite well...
meowsqueak