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.