Example: Data files from the Daimonin project (an MMORPG). They are
ISO-8859-1
text files. They must explicitely only use LF for line ending. They won't
work with CR/LF. The file format is specified to be plain text with LF line
endings only. The server and editor will not accept files with CR/LF.
So even if somebody checks out a CVS sandbox on Windows, the line endings
must
be LF, otherwise the files can't be used.
I'd say that they're not text files, in that they differ from the widely
used (and accepted, though debatable) format of the OS. In the same way
that...
[snip] CR/LF is a os-specific problem that's best handled in the text
editor.
the program reading the text should be able to handle the appropriate
line-endings for the platform. Otherwise, the program should not claim to
read "text files". Rather, they are reading binary files with XX-terminated
lines of text.
Even on Windows there are text editors capable of using NL only (gvim,
UltraEdit, Emacs, most IDEs and various others).
You seem to be primarily concerned with the utility to edit text files. How
about all the programs that parse text files? Should programs that read
their own configuration files be prepared to handle all possible line
endings?
And how about the other way around? Should vi on unix be adapted to support
CR/LF line endings? You certainly seem to suggest that it is wrong for
windows editors to only support the OS' native line endings, so how about on
unix?
[snip]
But regardless, if a cvs client changes a file upon checkin or checkout
other
than keyword replacement or diff patching, it eventually breaks the file,
see
above example.
I'd consider the app broken, not the text file.
Arno
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/info-cvs
