On 29/08/2017 18:58, Grant Drake wrote:
>
> 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
>
> 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?
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any
> retention, use or disclosure not expressly authorised by Markit is
> prohibited. This email is subject to all waivers and other terms at
> the following link:
> http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page
> for contact information on our offices worldwide.
Just quickly skimming through this mail, this sounds like the problem
described and investigated in late July:
http://mail-archives.apache.org/mod_mbox/subversion-users/201707.mbox/%3C5aae07a9-bb6d-6340-206a-dafcf91e35e6%40apache.org%3E
Note that the issue reported in that mail was not fixed in 1.8.19 (it's
currently expected to get into 1.8.20).
If you are in fact running into that described problem, try svnadmin
load -M 0 as a workaround. If that won't work, you are likely running
into a different issue here. As danielsh already suggested, try to
verify that indeed you don't have two different files with the same
sha-1 hash (I doubt that atm, though).
Regards,
Stefan
Received on 2017-08-30 03:03:47 CEST