cvs2svn - is dump file platform portable?

[Bo Berglund]

While investigating the methods to use when migrating our CVS
repositories from CVS to SVN I converted one of the smaller CVS
respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
Server 16.04.3 machine.

Then I moved the dump file over to the target Windows 2016 Server
where I had just installed VisualSVN and tried to use the VisualSVN
GUI tool to load the dump into a new repository. But it threw an error
box displaying:
"Could not convert ' 2' into a number"

Next I tried to load it from the command line:

svnadmin load \SVNREPOS\bosse < bosse-dump
' into a number04: Could not convert ' 2

Strange output and it stopped. Same basic error...

Then I went back to the Ubuntu machine and loaded the dump file into
svn there and it worked just fine.

So I made a dump from the newly loaded repository on Ubuntu and went
back to Windows 2016 and repeated the load command with the new dump
file.
This time it worked without errors!

So my question is:
Is the dump file format from cvs2svn platform dependent such that it
will not work if moved from Linux to load it on Windows?

It seems like dump files from svn itself work when moved between
platforms.
(Both systems have svn 1.9.7)

[Branko Čibej]

Post by Bo Berglund
While investigating the methods to use when migrating our CVS
repositories from CVS to SVN I converted one of the smaller CVS
respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
Server 16.04.3 machine.
Then I moved the dump file over to the target Windows 2016 Server
where I had just installed VisualSVN and tried to use the VisualSVN
GUI tool to load the dump into a new repository. But it threw an error
"Could not convert ' 2' into a number"
svnadmin load \SVNREPOS\bosse < bosse-dump
' into a number04: Could not convert ' 2
Strange output and it stopped. Same basic error...
Then I went back to the Ubuntu machine and loaded the dump file into
svn there and it worked just fine.
So I made a dump from the newly loaded repository on Ubuntu and went
back to Windows 2016 and repeated the load command with the new dump
file.
This time it worked without errors!
Is the dump file format from cvs2svn platform dependent such that it
will not work if moved from Linux to load it on Windows?

It should be. If it's not, then it's not a Subversion dump file and
there's a bug in cvs2svn.

-- Brane

[Stefan Sperling]

Post by Bo Berglund
While investigating the methods to use when migrating our CVS
repositories from CVS to SVN I converted one of the smaller CVS
respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
Server 16.04.3 machine.
Then I moved the dump file over to the target Windows 2016 Server
where I had just installed VisualSVN and tried to use the VisualSVN
GUI tool to load the dump into a new repository. But it threw an error
"Could not convert ' 2' into a number"
svnadmin load \SVNREPOS\bosse < bosse-dump
' into a number04: Could not convert ' 2
Strange output and it stopped. Same basic error...
Then I went back to the Ubuntu machine and loaded the dump file into
svn there and it worked just fine.
So I made a dump from the newly loaded repository on Ubuntu and went
back to Windows 2016 and repeated the load command with the new dump
file.
This time it worked without errors!
Is the dump file format from cvs2svn platform dependent such that it
will not work if moved from Linux to load it on Windows?
It seems like dump files from svn itself work when moved between
platforms.
(Both systems have svn 1.9.7)
--
Bo Berglund
Developer in Sweden

How did you copy the dump file from Windows to Ubuntu?

Beware of Windows tools which change line endings!
I have seen that happen before and it destroyed dump files.

Zip the dump file before copying it away from windows to make
sure it does not get mangled on the way.

[Bo Berglund]

Post by Stefan Sperling
How did you copy the dump file from Windows to Ubuntu?

cvs2svn was executed on Ubuntu. The dump file was gzipped and then
moved via FTP *to* Windows.

Post by Stefan Sperling
Beware of Windows tools which change line endings!
I have seen that happen before and it destroyed dump files.

Yeah, I have seen these as well but not for repository files. Scripts,
though, are vulnerable.

Post by Stefan Sperling
Zip the dump file before copying it away from windows to make
sure it does not get mangled on the way.

So I have two dump files:
bosse-dump made by cvs2svn
loads fine in svn on Ubuntu but errors out on Windows

bosse.dump made by svnadmin dump on Ubuntu based on the above load.
Gzipped and FTP:ed to Windows, loads fine using svnadmin load on
windows.

Unfortunately it is not possible to run a compare on them because
their sources are different and so diffs are everywhere, I believe.

Probably a cvs2svn problem....

[Nico Kadel-Garcia]

Post by Bo Berglund

Post by Stefan Sperling
How did you copy the dump file from Windows to Ubuntu?

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. 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. 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".)

Post by Bo Berglund

Post by Stefan Sperling
Beware of Windows tools which change line endings!
I have seen that happen before and it destroyed dump files.

Yeah, I have seen these as well but not for repository files. Scripts,
though, are vulnerable.

Post by Stefan Sperling
Zip the dump file before copying it away from windows to make
sure it does not get mangled on the way.

bosse-dump made by cvs2svn
loads fine in svn on Ubuntu but errors out on Windows
bosse.dump made by svnadmin dump on Ubuntu based on the above load.
Gzipped and FTP:ed to Windows, loads fine using svnadmin load on
windows.
Unfortunately it is not possible to run a compare on them because
their sources are different and so diffs are everywhere, I believe.
Probably a cvs2svn problem....
--
Bo Berglund
Developer in Sweden

[Bo Berglund]

On Wed, 13 Dec 2017 17:23:16 -0500, Nico Kadel-Garcia

Post by Nico Kadel-Garcia

Post by Bo Berglund
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...

Post by Nico Kadel-Garcia
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.

Post by Nico Kadel-Garcia
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.