W pewnym momencie, w dość dużym repozytorium (~300MB) wystawionym przez Apache (mod_dav) pojawił się problem:

$ svn up
svn: Decompression of svndiff data failed
$ 

Rzut oka w logi serwera:

[error] Provider encountered an error while streaming a REPORT response.  [500, #0]
[error] A failure occurred while driving the update report editor  [500, #104]
[error] Error writing base64 data: Connection reset by peer  [500, #104]

Po uruchomieniu svnadmin verify okazało się, że coś jest nie tak z rewizją 413:

$ svnadmin verify /var/repos/name
* Zweryfikowano wersję 0.
* Zweryfikowano wersję 1.
....
* Zweryfikowano wersję 411.
* Zweryfikowano wersję 412.
svnadmin: Decompression of svndiff data failed
$ 

Na szczęście istnieje fsfverify!

$ ./fsfsverify.py /var/repos/name/db/revs/413
NodeRev Id: 0.0.r413/12323283
type: dir
...
Error InvalidCompressedStream: Invalid compressed instr stream at offset 7116827 (Error -3 while decompressing: incorrect header check)
Try running with -f to fix the revision
$ ./fsfsverify.py -f /var/repos/name/db/revs/413
NodeRev Id: 0.0.r413/12323283
type: dir
...
Copy 289710 bytes from offset 7116813
Write 289710 bytes at offset 7116675
Fixed? :-)  Re-run fsfsverify without the -f option

Na koniec cytat ze strony fsfverify:

I’ve found that most corruptions happen on systems configured to use a threading model whether via svnserve or mod_dav_svn. If you have a system that supports forking, use either Apache’s mpm_prefork or make sure svnserve is not running in threaded-mode. That substantially reduces the chance of corruption.