[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Checksum mismatch with 1.9.7

From: Michael Knigge <michael.knigge_at_gmx.de>
Date: Sat, 9 Dec 2017 17:41:56 +0100

[At First: I've sent this post yesterday evening - but I guess it got
loste somewhere because I can not see this in the mail archive - sorry
if I post it double....]

Hi all,

I have a rather strange issue with Subversion 1.9.7 and I hope someone
of you can bring me in the right direction. I'm not able to load a dump
and/or svnsync to a new Subversion in version 1.9.7.

I've created a dump on a server running 1.8.19 and then I've tried to
load it on a 1.9.7 machine. I get this error:

svnadmin: E160004: Filesystem is corrupt
svnadmin: E200014: Checksum mismatch while reading representation:
    expected:  3168c2eb460868be4ec2e1a62084d80f
      actual:  67178f4abfbb0b876a260142c15f645b

I also get this error when i run "svnadmin load" with the "-M 0"
trick... On another machine running Subversion 1.8.10 I can load the
dump. So I assume the dump is ok (furthermore, a "svnadmin verify" on
the 1.8.19 server also runs successfully). Note that I was able to
export the file from this revision (with TortoiseSVN on Windows) and the
checksum is 3168c2eb460868be4ec2e1a62084d80f - so the "expected"
checksum in the dump is the right one.

Ok, I was not able load load the dump - so I tried svnsync. On the same
revision, the svnsync also stops:

svnsync: E160000: SHA1 of reps '51384 62 16385 20282
3168c2eb460868be4ec2e1a62084d80f
cc1652eaf2ef8cb91769dc4fea2d327413548c3e 51384-13nc/_21' and '-1 0 934
20282 3168c2eb460868be4ec2e1a62084d80f
cc1652eaf2ef8cb91769dc4fea2d327413548c3e 51384-13nc/_21' matches
(cc1652eaf2ef8cb91769dc4fea2d327413548c3e) but contents differ

I've searched the Mailing-List archive and came across other people
having problems like this (but for them "-M 0" did the trick). Sadly,
not for me....

Ok... what now? Is there a bug in 1.9.7? Or is Subversion on the server
side too old? Any ideas?

I guess I can get around this if I sync my repository on a Subversion
1.8.10 release, tar it and transfer it to the "right" destination
machine running 1.9.7.... (why I don't just copy the original
repository? We want to set up a live mirror using svnsync...)

But I'm fairly interested why I have this problems running 1.9.7 and
what is the right way around it...

Bye & Thanks,
Michael
Received on 2017-12-11 07:33:04 CET

This is an archived mail posted to the Subversion Users mailing list.