views:

604

answers:

3

This one has me scratching my head.

I'm running Subversion 1.3.1 (r19032) on Ubuntu. All was well until recently when I tried to run svnadmin verify prior to a dump. This is the error message:

svnadmin: Invalid diff stream: insn 0 cannot be decoded

I have looked around for an explanation and fix but can't seem to find one. Subversion experts, I need your help.

+3  A: 

You should ensure that you are using the correct version of svnadmin for your repository version. It's possible to get errors like this by using the wrong version.

Having said that, version 1.3.x is pretty old now and you should consider upgrading to the latest 1.5.x.

I also found through google that some versions of SVNKit can cause this problem.

Greg Hewgill
+2  A: 

I do not know how to fix your actual problem, unfortunately.

Regarding future preventive measures: I agree with Greg Hewgill: There are several known data repository corruption bugs in subversion 1.3.1. The last known one being patched in 1.4.6 (and also patched in all 1.5.x and all future versions of course). So you could upgrade to Ubuntu 8.04 (dapper drake), if possible, which comes with subversion 1.4.6 (as well as some ext3 file system patches). If you upgrade to dapper drake, make sure to reformat your ext3 partition with the dapper drake version of the e2fslibs and also do a bad block check with that (this might take several hours on big partitions): e2fsck -c -c -j /dev/

Also, in many cases it is not subversion being responsible for repository corruptions, but the underlying platform (i.e. the hardware in most cases). Subversion trusts the underlying platform and does not do checksumming by itself. This means that if you really have a valuable source code repository and do not want to have to play back backups of uncorrupted repository backup versions from time to time, than you should invest some money and put the repository on a dedicated box with ECC memory, Solaris operating system and ZFS file system on a 3-way RAID-1 ZFS-mirror (redundant zfs softare raid mirror on three drives). ZFS checksums every bit before it goes to the storage controller, which ext3 does not.

Hardware bit errors do occur again and again in real life. Subversion does not detect those. So you have to use an OS with a file system which does checksumming as well as ECC memory.

SAL9000
+1  A: 

I had this same error with svnadmin 1.5 awhile back after renaming files and directories. Specifically I renamed some files from "Filename" to "filename" and SVN pretended it was okay with this... only to freak out later when I tried doing a fresh checkout. When I tried a fresh checkout I got a weird abort message about the files not existing.

So this naturally led to me doing a svnadmin dump, followed by svnadmin verify only to get the same message that you specified.

I don't know of a fix. I worked around this problem like so:

  1. Dumped the next previous version of the repository and ran svnadmin verify on the dump.
  2. If error still occurs goto step 1.
  3. After verifying a good dump, I deleted the entire SVN repository, recreated it, and imported from the good dump file.

Make sure your dump file has all deltas so you get the change history up to the last good point.

I lost a bit of code, but not too much to be really painful.

ceretullis
That is something the SVN devs would like to hear about - SVN is supposed to be case insensitive, to the annoyance of Windows users :)
gbjbaanb