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

Reply via email to