On 22.01.2018 13:48, Nico Kadel-Garcia wrote: > On Mon, Jan 22, 2018 at 4:38 AM, Bo Berglund <bo.bergl...@gmail.com> wrote: >> On Mon, 22 Jan 2018 09:02:44 +0000, Scott Bloom <sc...@towel42.com> >> wrote: >> >>> 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 >>> >> OK thanks, >> I have now retrieved the latest CVS file versions on trunk and copied >> them into my svn working copy with the corrupted exe files so I could >> commit them to svn. And before I committed them I also explicitly set >> the file MIME properties to binary (using the SmartSvn properties >> dialogue). >> Now when I export trunk they are OK. >> So at least as long as one stays on trunk these files will be OK. > That makes sense. I'm glad you were able to work it out. > > Some folks, like me, consider EOL reprocessing on checking and > checkout to be a very dangerous habit and one that should be avoided > in source control systems, It works great, until it doesn't, as you've > just found.
... which is precisely why Subversion doesn't do this by default. But the moral of this whole story is this: After any major surgery on a version control system — and conversion from one system to another is certainly major — one should thoroughly verify the result before bringing it into production. -- Brane