Line endings go from CRLF to LF under Cygwin, but not with Tailor

[Doug Lee]

Under Cygwin (with its line endings set to DOS/Windows), converting a CVS repo to Bazaar with Tailor produces the expected CRLF endings in text files; but only LF endings result if I import the same project via cvsps-import. `cvs update -p ... >out.txt' in Cygwin produces CRLF endings in out.txt. I did not test the output of `co', but --use-cvs on cvsps-import does not fix the problem. I'm not sure if this is a cvsps issue, a straight cvs issue, a cvsps-import issue, or something else; but I'm trying to convert about 40 Windows-based CVS projects to Bazaar, and Tailor lost the race by missing all my CVS tags...

[John A Meinel (jameinel)]

I'm not sure what the problem is. I thought originally it might be the subprocess PIPE being opened in text mode. But my simple test:

>>> import subprocess, sys
>>> p = subprocess.Popen([sys.executable, '-c', "print 'hello'"], stdout=subprocess.PIPE)
>>> p.communicate()
('hello\r\n', None)

Shows that the CRLF is being preserved.

Internally we should be preserving exactly what was given by CVS/RCS.

I could try to help you debug it. You can add a line like:
=== modified file 'cvsps/importer.py'
--- cvsps/importer.py 2008-01-08 04:56:28 +0000
+++ cvsps/importer.py 2008-01-09 23:05:48 +0000
@@ -669,6 +669,7 @@
             txt = self._run_cvs(filename, cvs_revision)
         else:
             txt = self._run_co(rcs_file, cvs_revision)
+ import pdb; pdb.set_trace()
         return txt, executable

     @staticmethod

Which will drop you into the python debugger whenever a text is extracted. Which should allow you to see what the line endings are.

[John A Meinel (jameinel)]

Another possibility is that it is the version of python. I was testing with python 2.5.1.

[Doug Lee (dgl-dlee)]

>Another possibility is that it is the version of python. I was testing
>with python 2.5.1.

That's what I run also.

[Doug Lee (dgl-dlee)]

I now propose this problem be addressed with a new --force-eol option
that takes values of None (default), LF, CR, and CRLF. The primary
advantage of this is OS independence. It would allow me to convert my
Unix-hosted but Windows-accessed CVS repos on a Unix system and still
get CRLF in Bazaar as Windows will expect. At least until Bazaar
supports EOL conversion internally, Bzr is checking CRLF into branches
from Windows already; so this would produce Windows-compatible
histories for Windows projects, even on Unix hosts.

I actually tried to prepare a cvsps-import patch to submit, but I'm
hampered by (1) not knowing much Python, and (2) not knowing, with
either use_cvs or use_rcs, how best to get the -kb or non-kb status of
a CVS/RCS file. We'd need this to avoid doing any translation on -kb
files no matter what --force-eol says.

Thoughts welcome. If you want what I have, which is only the
command-line option and its help plus passage of the option as far as
importer.py::importer, let me know.

--
Doug Lee <email address hidden>
SSB BART Group <email address hidden> http://www.ssbbartgroup.com
Freedom is not the ability to have what we want. Freedom is merely the
ability to seek it. To be free defines what we can do, not what we can get.
(03/28/05)