svn 1.9.7: svnadmin: E200014: Checksum mismatch while reading representation:

[Philip Martin]

svnadmin: E160000: SHA1 of reps '6604 1765 12180 238060 091c0630eece721fea4cba1bd1c99ba5 8c58eef60c3e147f2056a65139adccdc5802a308 6606-53k/_19c' and '-1 0 12180 238060 091c0630eece721fea4cba1bd1c99ba5 8c58eef60c3e147f2056a65139adccdc5802a308 6606-53k/_19c' matches (8c58eef60c3e147f2056a65139adccdc5802a308) but contents differ
svnadmin: E160004: Filesystem is corrupt
expected: 091c0630eece721fea4cba1bd1c99ba5
actual: 80e7786616c0f5b9a12cf6a99cb2acf6
Is this a corruption in my original repository that is only noticed
when trying to load after dump? Is this a bug it the loader? Is
there any more information I can provide to help debug this?

That is probably issue 4722:

https://issues.apache.org/jira/projects/SVN/issues/SVN-4722

It's a 1.9.7 bug in the SHA1 collision detection code and will be fixed
in 1.9.8. There is no corruption in your repository.

[Rolf Campbell]

I tried upgrading to subversion v1.10.0, and with that version of svnadmin, the load worked without any trouble.

From: Rolf Campbell <***@solace.com>
Sent: Sunday, May 13, 2018 10:05
To: ***@subversion.apache.org
Subject: svn 1.9.7: svnadmin: E200014: Checksum mismatch while reading representation:


I'm trying to dump and load a few dozen svn repositories and one of them fails with this message on the load:

svnadmin: E160000: SHA1 of reps '6604 1765 12180 238060 091c0630eece721fea4cba1bd1c99ba5 8c58eef60c3e147f2056a65139adccdc5802a308 6606-53k/_19c' and '-1 0 12180 238060 091c0630eece721fea4cba1bd1c99ba5 8c58eef60c3e147f2056a65139adccdc5802a308 6606-53k/_19c' matches (8c58eef60c3e147f2056a65139adccdc5802a308) but contents differ
svnadmin: E160004: Filesystem is corrupt
svnadmin: E200014: Checksum mismatch while reading representation:
expected: 091c0630eece721fea4cba1bd1c99ba5
actual: 80e7786616c0f5b9a12cf6a99cb2acf6

It fails while trying to load rev 6607. I've searched the archives and tried everything that I understood. I tried the -M0 option (no change). I tried doing the operation locally on the server. I tried using svnrdump. I tried using svnsync (it gets svnsync: E210008: Error while replaying commit). An "svnadmin verify" does not find any problem on either the original repository on the server, or the partial repository (after the failed load).



Both server and client are running svn 1.9.7 (the server was originally running 1.6.6 and was recently upgraded). Server is running on CentOS7, client is running on CentOS6.5. I even tried it on a Fedora27 installation (also running svn 1.9.7) with the same results.



Is this a corruption in my original repository that is only noticed when trying to load after dump? Is this a bug it the loader? Is there any more information I can provide to help debug this?