subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Eckhardt <>
Subject Re: Checksum mismatch creating repository?
Date Fri, 09 Jul 2010 09:12:56 GMT
On Friday 09 July 2010, Arivan S. Bastos wrote:
> This week, the disk of our server burned and then we decided to upgrade the
> windows 2008 server to Windows Server 2008 R2.
> After the upgrade we are facing problem with the use of Subversion.
> We try to use VisualSVN 2.1.2 and CollabNet 1.6.12, and also tried going
> back to version 1.4.6 (the version we used before the OS update), but
> always facing the same error:
> "error: svn: Checksum mismatch for #FILENAME#"

Is this a verbatim copy of the error or is this for various values of 

> The error happens when creating the repository using the command "svn
> import" to add

Wait: Why are you importing anything there? When migrating servers, I'd use 
the following steps:
1. Create dumpfiles on the old machine (this is part of the daily backup, 
actually) and save the configuration (conf/ subdir of the repository).
2. If the SVN versions are similar, copy the repository to the new machine. 
Otherwise, load the dumpfile into an empty repository and restore the 
3. If the machine's hostname/IP isn't the same as the old one, convert working 
copies using "svn switch --relocate".

Of course, importing can be part of the normal workflow, too, but then I'd 
wonder if other operations on the new repository work, i.e. if it is only 
imports that fail.

> , and always seems to occur in large files over 100Mb. If we insist on
> trying to send the file, sometimes it is sent. However, when trying to
> perform the checkout (on client side) we got"cannot read chunk size"
> somewhere in the checkout, and looking at the apache log, we see the
> same "Checksum mismatch".
> Using the same version of subversion, performing the same procedures on the
> same files on a computer running windows 7, this error does not occur.

Actually, I'm still not sure what exactly you did and on what machines. One 
additional way to circle in the problem would be to access the repository 
using direct file:// access.

> It seems that there is some limitation of use of resources, because this
> seems to happens with large files only.

I'm not running Apache here, but I seem to remember some kind of timeout there 
from a recent discussion. Obviously, using a large file or a slow connection 
it needs more time and thus also takes you closer to that timeout.



Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
           Visit our website at <>
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und
kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend,
falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu
löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen
enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

View raw message