Re: [boost] [assign, python, range] New inspection errors..

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: 
>>> http://www.boost.org/regression-logs/inspection_report.html#python
>>
>>
>> Fixed. 
> 
> 
> Hmm, doesn't seem to be fixed in CVS. Did you forget to check in the 
> changes?
> 
>> 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:

<quote>
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 
here.

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 
automatically.

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.
</quote>

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net