subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Bloom <sc...@towel42.com>
Subject RE: Exe files corrupted in SVN after import from CVS
Date Mon, 22 Jan 2018 09:02:44 GMT
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@gmail.com] 
Sent: Sunday, January 21, 2018 11:42 PM
To: users@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@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


Mime
View raw message