On 22.01.2018 13:48, Nico Kadel-Garcia wrote:
> On Mon, Jan 22, 2018 at 4:38 AM, Bo Berglund <bo.berglund_at_gmail.com> wrote:
>> On Mon, 22 Jan 2018 09:02:44 +0000, Scott Bloom <scott_at_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
Received on 2018-01-22 14:03:58 CET