[assign, python, range] New inspection errors..
Latest results of running the inspection tests: * Thorsten Ottosen you need to fix your editor to not insert TABS into code, see: http://www.boost.org/regression-logs/inspection_report.html#assign - and, http://www.boost.org/regression-logs/inspection_report.html#range * 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 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:41073319.6050609@redshift-software.com... | Latest results of running the inspection tests: | | * Thorsten Ottosen you need to fix your editor to not insert TABS into | code, see: | http://www.boost.org/regression-logs/inspection_report.html#assign - | and, http://www.boost.org/regression-logs/inspection_report.html#range Thanks! I did run the inspect tool on the library files, but forgot about the tests. br Thorsten
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. I'm investigating why my CVS client commits inconsistent line endings. Thanks, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
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. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
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
Joel de Guzman <joel@boost-consulting.com> writes:
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.
When you install Cygwin, you get the choice of whether to use Windows newlines or Unix newlines. The only reason I can see that you might want to use Unix newlines is if you were going to cross-mount your CVS tree between a Windows and a Unix box. If you set Cygwin to use Windows newlines you won't have these problems. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (4)
-
David Abrahams -
Joel de Guzman -
Rene Rivera -
Thorsten Ottosen