Nathan Hartman <hartman.nat...@gmail.com> writes: > That makes me wonder why this has not triggered more frequently for > users? Is there some obscure set of circumstances that triggers this > code path in this particular way? If so, can a test be added to the > test suite to prevent this sort of thing from slipping in again?
When the client sends a file it sends either a delta or a fulltext. The backend reconstructs the fulltext and then computes a new delta as a candidate to be stored in the repository. This delta gets written to the protorev file and if the length of the delta is a multiple of 16384 then the bug occurs. After a bit of playing around I've got a test case: svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1 (for i in `seq 0 8712`;do echo -n $i;done && echo -n 11111) > f1 svnadmin create repo svnmucc -mm -U file://`pwd`/repo put f1 f svnmucc -mm -U file://`pwd`/repo put f2 2 svnmucc -mm -U file://`pwd`/repo put f1 f The third commit fails: svnmucc: E160000: SHA1 of reps '1 0 17791 55700 df5d0e251e4b811f0ed63694e7a2cd00 fb07bf4d765ccf4e18afe74d559f3b16f916a1e1 2-2/_1' and '-1 0 17793 55700 df5d0e251e4b811f0ed63694e7a2cd00 fb07bf4d765ccf4e18afe74d559f3b16f916a1e1 2-2/_1' matches (fb07bf4d765ccf4e18afe74d559f3b16f916a1e1) but contents differ svnmucc: E160004: Filesystem is corrupt svnmucc: E200014: Checksum mismatch while reading representation: expected: df5d0e251e4b811f0ed63694e7a2cd00 actual: c833ae35c9e02f2b4069d3b1a31d4de0 If you look at the protorev in the failed transaction it starts: $ od -c repo/db/txn-protorevs/2-2.rev | head -1 0000000 D E L T A 2 0 1 6 3 8 4 \n -- Philip