RE: Exe files corrupted in SVN after import from CVS

When I have used cvs2svn, I had a couple of these issues as well..

It came down to improper settings on the cvs side, but since the binary files were never modified, there was no corruption due to cvs thinking it was a text file.

What I wound up doing, was simply finding all the expected binary files... and re-checking them in, after the conversion with proper SVN settings.

Scott

-----Original Message-----
From: Bo Berglund [mailto:bo.berglund_at_gmail.com]
Sent: Sunday, January 21, 2018 11:42 PM
To: users_at_subversion.apache.org
Subject: Re: Exe files corrupted in SVN after import from CVS

On Sun, 21 Jan 2018 22:23:21 -0600, Ryan Schmidt <subversion-2018_at_ryandesign.com> wrote:

>
>On Jan 20, 2018, at 10:25, Bo Berglund wrote:
>
>> I have found that there is a problem in our SVN repository, which was
>> converted from CVS using cvs2svn 2.5.0.
>>
>> It concerns two exe files which are corrupted when I check out or
>> export them. The trunk files have been expanded by 905 bytes or
>> shrunk by 119 bytes in the two cases. Both are in the same project.
>> They have
>> 82 and 67 commits into them respectively.
>
>Did you or your conversion process set the svn:eol-style property on
>these files? If so, that's why they got corrupted; you mustn't set that
>property on binary files.

Well, most of the exe files got converted without this problem, so it could not really be a global mistake in the way file properties are set.

This is how I configured individual conversions, the remaining options file content stayed the same for all repos:

outdumpfile='pc-dump'
inputreponame='PC'

This is my options settings for the cvs2svn conversion regarding properties, mostly defaults in the options file example from cvs2svn):

ctx.file_property_setters.extend([
    CVSBinaryFileEOLStyleSetter(),
    CVSBinaryFileDefaultMimeTypeSetter(),
    DefaultEOLStyleSetter(None),
    SVNBinaryFileKeywordsPropertySetter(),
    KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE),
    ExecutablePropertySetter(),
    DescriptionPropertySetter(propname='cvs:description'),
    SVNKeywordHandlingPropertySetter(),
    SVNEOLFixPropertySetter(),
    ])
ctx.revision_property_setters.extend([
    ])

and this is how the CVS top level directories were treated as "projects" during conversion:

# 1)List all projects automatically
import os
cvs_repo_main_dir = '/home/bosse/CVSREPOS/' + inputreponame projects = os.listdir(cvs_repo_main_dir)

# 2) Probably you don't want to convert CVSROOT:
projects.remove('CVSROOT')

# 3) Now loop projects and add to conversion list for project in projects:
    run_options.add_project(
        cvs_repo_main_dir + '/' + project,
        trunk_path=(project + '/trunk'),
        branches_path=(project + '/branches'),
        tags_path=(project + '/tags'),
        symbol_strategy_rules=global_symbol_strategy_rules,
        )

So, the options file stayed the same for all 8 CVS repositories except regarding the definition of the repo to convert and the output dump file name. Also I have not (yet) found any more corrupted exe files than these two that were compiled using Borland C++Builder and had CVS revision files with a huge size of 487Mb and 367Mb respectively.

Therefore I suspect that either the RCS file size itself caused a problem for cvs2svn, or there is some kind of internal exe file byte pattern in such files that triggers an action in cvs2svn which causes the file corruption...

The Ubuntu 16.04 Server (virtual machine) on which I ran the conversion has a RAM allotment of 2 GB, maybe this is too little when dealing with these huge files?

Checking out these files from CVS, even very old revisions from say 2006, still works successfully.

--
Bo Berglund
Developer in Sweden