[Ecls-list] build.vc8 files in mac format

[Dean O'Connor]

Thanks for changing the files.

True, the CVS server-side doesn't care about line endings, but the CVS 
client-side seems to have adopted this role for some platforms (like 
Windows).
I guess *nix clients don't probably because LF was all they knew, but it 
does seem very common on Windows CVS clients (think WinCVS does it).
I guess cause many Windows apps need it.

I was just in the process submitting a email to the TortoiseCVS mailing 
list to request that, though they knocked back my bug request, to 
consider handling this situation better by translating LF->CRLF and 
leaving any existing CRLF alone.

But then I came across this text from someone in a similar situation 
(See "Remaining Issues #2):
http://coweb.cc.gatech.edu/cs2340/3667

So if any Windows CVS client was to do smart-er translation (LF->CRLF 
and leave CRLF alone) then there might be two issues:
- there might be merge problems (as above link mentioned)
- check-in's would essentially have to always check-in a consistent 
newline, LF seems to be the accepted one, so essentially any original 
CRLF's in the file would be *modified* to LF.

So I don't really see where it is written that all text files should be 
stored CVS as LF only,  but I guess the consequences of not doing that 
will cause issues cross-platform.

If Windows CVS's clients did no newline translation then a lot of 
Windows programs would have to handle *nix newlines and visa-versa. I 
guess in a perfect world they would :)

So I still might submit the email to the TortoiseCVS users mailing list 
to hear their viewpoint.

cheers
deano

Juan Jose Garcia-Ripoll wrote:
> 007/2/13, Dean O'Connor <dean.oconnor at ite.com.au>:
>   
>> It does make sense because when I check out those problem files in linux
>> they do have CR-LF instead of just LF.
>>     
>
> TortoiseCVS is simply broken. The problem with it is that it attempts
> to translate all files with unix file endings LF (or \n) into DOS
> convention CR+LF (\r\n). It assumes that no file in CVS will carry the
> DOS line ends characters.
>
> "CVS internally stores line endings in UNIX style. So when committing
> a Windows-style text file to CVS, <CR><LF> 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 <CR><LF> before writing it to a sandbox on a Windows
> system. CVSNT by default does all those conversions automatically."
>
> As you see the first sentence is plain wrong. CVS does not care about
> line ending conventions. It can handle DOS, Unix or Mac. It will
> simply not modify the line endings of your files. That is what any
> reasonable client will do, either Linux, BSD, Mac, or Cygwin/Mingw.
>
> I will change the line endings in all files to be Unix like. But my
> feeling is that this is wrong on the TortoiseCVS side.
>
> Juanjo
>
> --
> Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
> Ciudad Universitaria s/n Madrid 28040 (Spain)
> http://teorica.fis.ucm.es/~jjgarcia/
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
>