Grant Drake wrote on Tue, 29 Aug 2017 16:58 +0000:
> Our current Subversion server is 1.8.5. We are trying to setup a replacement server, on which I have installed 1.8.19.
>
> The svnadmin load command on the 1.8.19 server for one of the repository dump files only comes up repeatedly with this error about 80% of the way through the revisions:
>
> svnadmin: E160000: SHA1 of reps '-1 133 284 793 a21e1fc00eb3e762b9b269b65b16a7bc ac7b8b00ada08b3e6bba37a0be206ad5faab70c1 6476-4zw/_a' and '-1 641 284 793 a21e1fc00eb3e762b9b269b65b16a7bc ac7b8b00ada08b3e6bba37a0be206ad5faab70c1 6476-4zw/_a' matches (ac7b8b00ada08b3e6bba37a0be206ad5faab70c1) but contents differ
Does it load successfully if you disable rep-sharing in fsfs.conf on the
1.8.19 repository?
The two -1's imply that both sides of the collision are part of the same
revision --- the revision that 'load' fails to commit. Inspect that
revision on the 1.8.5 server. Does it, by any chance, really add two
different files with the same sha1?
> svnadmin: E160004: Filesystem is corrupt
> svnadmin: E200014: Checksum mismatch while reading representation:
> expected: a21e1fc00eb3e762b9b269b65b16a7bc
> actual: ac1cc0244040d0134191ec8cec175e1f
>
> I have run svnadmin verify on the original server repo, it shows no indication of corruption.
>
> What can we do? Must we upgrade the original source server to 1.8.19 in order to produce a new dump file that can be loaded?
I don't expect that would help. This doesn't seem like a bug in the dump code.
Received on 2017-08-30 01:54:30 CEST