svnadmin: Svndiff contains a too large window

When I am trying to l开发者_运维问答oad / restore my SVN repositories, I get the error:

svnadmin: Svndiff contains a too large window

How can I resolve this?

Since I ran into this today...

There is likely a corrupted revision in your svn repository with the FSFS database.

BACKUP YOUR SVN REPOSITORY.

Determine if your repository is packed/sharded by reading ${REPO}/db/format

[root@chi2 db]# cat format
4
layout linear

If your fsfs database is 'layout sharded' you'll need to obtain fsfs-reshard.py from here: http://ymartin59.free.fr/wordpress/wp-content/2010/07/fsfs-reshard.py

(This is version works on 1.6+ greater repositories and this guy's patch still hasn't been ported to svn trunk).

Run the following to unpack the repository:

./fsfs-reshard.py ${REPO} 0

Run verify:

svnadmin verify ${REPO}

* Verified revision 13689.
* Verified revision 13690.
* Verified revision 13691.
svnadmin: E185001: Svndiff contains a too-large window

The revision that was errored out was the revision 1 greater than the last verified revision, our bad rev is 13692.

Obtain fsfsverify.py from Subversion trunk. http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py

Run fsfsverify.py on your bad revision. You may need to run the -f option two or more times. This will spit out a lot of data but eventually it should come clean.

[root@chi2 archive]# ./fsfsverify.py -f ${REPO}/db/revs/13692
Copy 4640123 bytes from offset 1006867
Write 4640123 bytes at offset 1003542
Fixed? :-)  Re-run fsfsverify without the -f option
[root@chi2 archive]# ./fsfsverify.py ${REPO}/db/revs/13692

Run svnadmin verify again. Repeat above process for any further bad revisions.

Once you have a verified repository, you can repack by running

./fsfs-reshard.py ${REPO} 1000

Run svnadmin verify yet again!

Your SVN Repository should be OK!

I've found the cause of this problem, which may in turn be able to help you solve it - although this will depend very much on the type of files you have in the repository.

Files in SVN get recorded by name AND by their file hash (I believe they're MD5'd). If you delete the file and then try uploading the same file again, SVN remembers the hash, and instead of creating a new base delta file, it will point it to a previous revision where it existed.

At some point in the life of your repository, your file has become "poisoned". Any files that match the MD5 of your file (regardless of the commit path) will fail the svndiff process (for reasons still not entirely clear) because SVN tries to use the old and broken revision. If you want to "fix" the problem, modify the file locally (if its code, try adding a blank comment) and this will cause the MD5 to change. After deleting the file and committing the new "fixed" version, service should resume as normal.

Now, back to my first paragraph - this solution is only really going to work with files you can afford to change. If, for example, you've got a 100MB video file - then you will need to modify it in some way as to change the hash. It gets even worse if you're working with executable files, as these are notoriously difficult to modiy post-compilation.

My recommendation would be as follows:

• If it is a text-based file, try to make cosmetic chances (e.g., blank comments, extra newline, etc.)
• If it is an executable binary, try to recompile it.
• For all other binaries (images, videos, etc.) you will need to get clever with the way in which you modify it.

I hope this is of some help, it has been a real pain getting to the bottom of this issue.