Platform:
debian 6.0.1 "squeeze",
subversion 1.6.16dfsg-1+b1,
fsfsverify.py from http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side
python 2.6.6-3+squeeze6
(information about the repository at the end of this mesage)
Yesterday I discovered that my subversion repository is broken. Trying
to do "svnadmin dump" breaks at revision 683:
sb_at_somehost:/tmp/svnrepo$ svnadmin dump /tmp/svnrepo/svn/ >/dev/null
* Dumped revision 0.
* Dumped revision 1.
...
* Dumped revision 681.
* Dumped revision 682.
svnadmin: Decompression of svndiff data failed
I found some threads on this list of people with the same error message
suggesting to use fsfsverify.py. I assumed that the trunk version from
the repository would be the newest and most stable so that's the version
I've tried.
I've done all of my experiments with fsfsverify.py, and one attempt at
using fsfsfixer, on a copy of the repository, created with the command:
(cd /tmp/svnrepo; rm -rf svn; cp -a /usr/local/svn/ .)
The first run of fsfverify.py /tmp/svnrepo/svn/db/revs/0/683 reports the
following:
...
NodeRev Id: 4-683.0.r683/12232
type: file
text: DELTA 683 1910 890 1548 30aadd70339eb7b41ab6eb20a6220202
prop: PLAIN 683 12138 81 0 685faf6a4230ea531a31a12e4b3cb565
cpath: /trunk/someprog/metamodeller/Makefile.msvc
copyroot: 0 /
<Svndiff so: 1916 ver: 1>
Error InvalidCompressedStream: Invalid compressed data stream at offset 2247 (Error -3 while decompressing: incorrect data check, <Window wo:1920 so:0 sl:0 tl:1548 cil: 317 cdl: 561 il:315 dl:729 whl:8 wl:886>)
Try running with -f to fix the revision
When I run fsfsverify.py -f /tmp/svnrepo/svn/db/revs/0/683 I see:
...
NodeRev Id: 4-683.0.r683/12232
type: file
text: DELTA 683 1910 890 1548 30aadd70339eb7b41ab6eb20a6220202
prop: PLAIN 683 12138 81 0 685faf6a4230ea531a31a12e4b3cb565
cpath: /trunk/someprog/metamodeller/Makefile.msvc
copyroot: 0 /
<Svndiff so: 1916 ver: 1>
Copy 893 bytes from offset 1920
Write 893 bytes at offset 1916
Fixed? :-) Re-run fsfsverify without the -f option
Which looks good. However, fsfverify.py /tmp/svnrepo/svn/db/revs/0/683
reports:
...
NodeRev Id: 4-683.0.r683/12232
type: file
text: DELTA 683 1910 890 1548 30aadd70339eb7b41ab6eb20a6220202
prop: PLAIN 683 12138 81 0 685faf6a4230ea531a31a12e4b3cb565
cpath: /trunk/someprog/metamodeller/Makefile.msvc
copyroot: 0 /
Traceback (most recent call last):
File "/tmp/scripts/fsfsverify.py", line 1190, in <module>
options.dumpWindows)
File "/tmp/scripts/fsfsverify.py", line 581, in verify
svndiff = Svndiff(f, self.length)
File "/tmp/scripts/fsfsverify.py", line 472, in __init__
(self.startingOffset)
__main__.InvalidSvndiffHeader: Invalid svndiff header at offset 1916
This is also the same error message I get on all subsequent runs of
fsfverify -f. I have tried 15 runs (all with the same output), since
the author of fsfsverify.py, said in an article on this list, that he
once had to run it 14 times.
All assistance on this issue will be welcome.
Thanks!
- Steinar
Some information on the repository:
- The size of the repository is 22MB
- The repository has 1794 revisions
- The repository was converted from CVS to a BDB svn repository, with
cvs2svn in May 2007
- In february I discovered that the repository was BDB (I had assumed
it was FSFS) because of a BDB upgrade problem
nntp://news.gmane.org/gmane.comp.version-control.subversion.user/86556
http://thread.gmane.org/gmane.comp.version-control.subversion.user/86556
- According to the articles in the above thread, I was able to dump the
repository, and create a new FSFS repository in February 2009
- I have used svnmerge to track merges between different branches
- The server installation of svn has been whatever has been on debian
stable for the repository's entire lifetime
- The clients have been a multitude of different svn clients, with
different versions on different platforms
- I have also used many different versions of svnmerge, with many
different versions of python
- svnmerge has not been used on the parts of the repository that has
problems
- Revision 683 is from December 2005, ie. well before the transition
from CVS to subversion (has been through the transition from CVS to
svn, and the 2009 transition from BDB to FSFS)
- The svn checkouts outside of the problem area seems to work just
fine
- The area that has the problem isn't important to me (I can't even
remember what it was about), but history both before and after,
outside of the problem area, is (it's the history of my home
directory config files, ie. .bashrc, .emacs and the like)
Received on 2011-05-14 10:59:07 CEST