On Wed, 13 Dec 2017 17:23:16 -0500, Nico Kadel-Garcia
<nkadel_at_gmail.com> wrote:
>> cvs2svn was executed on Ubuntu. The dump file was gzipped and then
>> moved via FTP *to* Windows.
>
>FTP can manipulate line endings, depending on its settings.
That is one reason why I compressed the file (gzip) before sending it
by FTP, and the second is to reduce the transfer size...
>I urge you to stop trying to change two things in one step, namely the version of
>Subversion and the OS or binaries for Subversion at the same time.
I don't understand this comment...
I am not changing anything here except the platform, both on Linux and
Windows I run svn 1.9.7 so there is no difference there.
>If you have to do loads and conversions on the Windows server, use the
>CygWin version of subversion, which is much more consistent and robust
>in its Subversion server behavior. (That is "in my experience".)
The reason I brought in Ubuntu 16 Linux is to do the conversion from
CVS to SVN on a linux platform (which is less troublesome in general).
So I used cvs2svn 2.5.0 to make the actual conversion to the dump
file.
But what I did not do at first was to load the cvs2svn dump on the
Linux side svn and then make a new dump from that. The reason is that
each repository took upwards of an hour to convert by cvs2svn and
importing the dump to svn was another delay of the same size as was
the subsequent dump.
So instead of looking at conversion time T I would have 3*T if the
dump file is indeed not compatible to Windows svn and I have to "wash"
it through Linux svn....
Since it loads just fine on Linux I assume that whatever problem there
is is in the cvs2svn conversion on Linux making "something" that is
not liked by svn on Windows even though they are the same version.
I will make more tests tomorrow, I have used the smallest dump file so
far in my testing in order not to waste so much time. The 3 largest
dumps are 5-7 GB each.
--
Bo Berglund
Developer in Sweden
Received on 2017-12-14 00:40:56 CET