info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: line endings in text files and -kb


From: Arthur Barrett
Subject: RE: line endings in text files and -kb
Date: Fri, 12 Sep 2008 08:44:19 +1000

Paul,

> If you check the file out on the platform for which the text is  
> ultimately destined, you would not have this problem.  Check it out  
> on Windows, it works on Windows.  Check it out on Linux, it works on  
> Linux.  Under no circumstances, using CVS or not, should you expect  
> text files on one platform to work on the other when simply mounted  
> or copied bit-for-bit.

I think part of the problem here is the tendancy for some people (mostly
programmers) to treat windows as unix (or put another way - to fail to
obey windows rules on windows).

Several examples of this are:
* IDEs on windows that read LF terminated text files
* Compilers on windows that read LF terminated text files

So people using windows become accustomed to the 'fact' that windows
understands LF terminated text files.  Along comes a program like CVS
that does not try and mix its metaphores and people claim CVS is broken.
No programmer or user of HPUX would ever accept any program running on
HPUX that opened a text file and 'auto-discovered' it's line endings and
presented it perfectly - if it has LF line endings it works and anything
else will show up as rubbish.  Windows (being more popular?) has become
its own worst enemy - by becoming more 'usable' it's also broken its own
rules.

One solution is for tools like CVS to treat windows text files the same
way - 'intelligently' determine the line type rather than believe the
'windows rule book' that windows text files have CRLF.  This of course
means throwing away the C RunTime (CRT) which will then break easy
portability (which is generally considered important for the CVS
project).  In CVSNT we've experimented with this approach - basically
trying to use auto detected mime types instead of hard and fast rules -
generally with pretty poor results always forcing us back to defined
line endings - with -k+L/-k+M/-k+D as the only viable alternative.  In
the latest CVSNT 2.5.04 we've attempted to be more aggressive at 'auto
fixing' broken line endings on checkin - but since this release is not
stable yet we've limited feedback on how this performs in the real
world.

Regards,


Arthur Barrett






reply via email to

[Prev in Thread] Current Thread [Next in Thread]