From: Joel de Guzman (joel_at_[hidden])
Date: 2004-07-28 22:39:16
Rene Rivera wrote:
> Joel de Guzman wrote:
>> Rene Rivera wrote:
>>> * Joel de Guzman you need to fix your editor and possibly CVS setup
>>> to insert consistent end-of-lines, see:
> Hmm, doesn't seem to be fixed in CVS. Did you forget to check in the
>> I'm investigating why my CVS client commits inconsistent
>> line endings.
> Are you using TurtouseCVS? Others have had problems with it. It seems to
> want to use a specific type of EOL (Unix LF). Which on Windows is
> different than most editors are set to deal with.
Yes. And I found out why:
It's highly recommended not to access your repository (that was checked out with
TortoiseCVS, CVSNT or WinCVS) using Unix-style CVS clients (like Linux's or
Cygwin's) because of line ending incompatibilities.
You should *only* access a repository using CVSNT, either directly from the
command line or through wrapper applications like WinCVS that use CVSNT internally.
If you'd like to know the details, continue reading. If that satisfies you, stop
Okay, I've warned you ;)
In Windows, text file line endings consist of the byte sequence CRLF ($0D$0A),
while Unix line endings only consist of a single LF ($0A). Loading a Unix-style
text file on Windows (or vice versa) may cause errors. Therefore, to be able to
share text files across platforms, line endings have to be converted.
CVS internally stores line endings in Unix style. So when committing a
Windows-style text file to CVS, CRLF has to be converted to LF before storing it
on the CVS server. The opposite when updating: When a text file is downloaded
from the CVS server, LF has to be converted to CRLF before writing it to a
sandbox on a Windows system. CVSNT by default does all those conversions
But other CVS clients don't do those conversions. Now, assume you commit a
Windows-style text file using a non-CVSNT client. As this CVS client won't
convert the line endings before uploading the file to CVS, the server repository
will contain CRLF line endings instead of LF. This leads to the following problems:
* If you check out the file on Unix (where no conversion is performed), the
line endings will be CRLF and not LF, which is wrong.
* If you check out the file on Windows using CVSNT, it will convert each LF
to a CRLF to set the corret line endings for Windows. Unfortunately, the server
copy of the file already *had* a CR before the LF. As a result, the local line
endings will be CRCRLF - the file is totally screwed up.
BTW: The above applies only to text files - binary files (keyword expansion -kb)
are never converted.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk