subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CHAZAL Julien <>
Subject RE : SvnAdmin: impossible to load dump generated by "cvs2svn"
Date Fri, 28 Sep 2012 09:15:03 GMT
Hi Markus,

Thanks a lot for your help ! ;-)

I followed your recommendations by checking file validity with the help of md5 sum. It wasn't
the same md5 sum on the two servers so I followed the procedure below :
- regenerate dump file with CVS2SVN tool
- generate md5 sum on an CVS server
- compress dump file in TAR GZ mode
- transfer the dump file in SFTP binary mode on SVN server
- untar and unzip the dumpfile
- generate md5 sum on an SVN server and compare md5 sum on both servers
- load the dump file with svnadmin command

So my issue is resolved. Cheers!!!

De : Markus Schaber []
Date d'envoi : lundi 10 septembre 2012 11:48
À :
Cc : CHAZAL Julien
Objet : AW: SvnAdmin: impossible to load dump generated by "cvs2svn"

Hi, Julien,

Von: CHAZAL Julien []

> I manage a Subversion server that has the following configuration :
> - SVN 1.6.9
> - FSFS storage mode
> - Apache + mod_dav + subversion modules
> - Linux Suse Enterprise Edition 32-bit
> I have to perform a CVS to SVN migration.  I use the tool "cvs2svn" to generate a dump
file from my CVS server and I use the "svnadmin" command to load this dump file on my Subversion
target server. I use a binary transfer mode with SFTP when I have to move a dump from my former
CVS server to my SVN server.
> I did this operation for many CVS repositories and it works fine, except for ONE repository
(size around 300 MB) where I encounter the following error:
> - 'vnadmin: Dump stream contains a malformed header (with no ':') at '
> I tried to regenerate many times my dump file from cvs2svn tool. I checked the header
of this dump fil and it sounds good (I compared it with other dump from cvs2svn tool). I took
a look on the web and I find a command to clear the dump file obtained by cvs2svn,  but anyway,
it doesn't work too: I can't load this dump file. As I have ever said, the error above concern
an only ONE cvs repository. Actually, I can load all others repositories from the same CVS
server to the same SVN server by using the same commands and  operations.
> You'll find below the commands I use to perform my migration :
> - CVS side: cvs2svn --dumpfile=DUMP_FILE.dump CVS_REPO --symbol-default=heuristic --encoding='latin1'
> - SVN side: svnadmin load MY_REPO_PATH < DUMP_FILE.dump
> Is there somebody know the reason why I encounter this error? Any idea about how to resolve
this issue?

Just to exclude systematic dump corruption during the transfer between those 2 machines:

Could you use md5sum or sha256sum or a similar tool to verify that the dump file is still
identical on the second machine?

Best regards

Markus Schaber
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: | Web:
CoDeSys internet forum:
Download CoDeSys sample projects:

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten
HRB 6186 | Tax ID No.: DE 167014915


Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de
ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe
Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts
soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne
aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage
résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability
cannot be triggered for the message content. Although the sender endeavors to maintain a computer
virus-free network, the sender does not warrant that this transmission is virus-free and will
not be liable for any damages resulting from any virus transmitted.

View raw message