"Bert Huijben" <b...@qqmail.nl> writes: >> What I find is that the problem sometimes appears and sometimes does >> not. It's not predictable either, repeating a failed export/checkout >> will sometimes work and sometimes fail at a different place. That is >> the case when I try that neon URL: >> >> svn: E200014: Checksum mismatch for >> 'subversion/tests/xx/src/ne_openssl.c': >> expected: 3bd789b372ca14793e8ac228cdf43a15 >> actual: be72d4221d805da2484b1cd0182b9049 >> >> svn: E200014: Checksum mismatch for 'subversion/tests/xx/src/ne_ssl.h': >> expected: 6fbb6c5dda02229623c887a9a08b1533 >> actual: 4f0c8e04845b70ebf1e88adbb780a2f0 >> >> I suspect the pool/memory handling in serf or libsvn_ra_serf, but I'm >> not certain. > > The update in one fetch operation in neon doesn't receive all checksums in > all places. Serf receives a few more, because it uses a request per file. > For trunk I fixed the missing checksums for 1.7, so a trunk server with a > trunk client gets all the checksums editor v1 supports. > > But using an older server or an older client will not. In that case you just > get the calculated checksums in your working copy. > > I think this server is pre 1.5, but it is certainly possible to get invalid > checksums in a checkout when you encounter the problems mentioned in issue > #3711. But you don't encounter these problems with trunk clients.
I was getting those checksum errors while doing an export, I'm not sure how 3711 is relevant. -- Philip
