Re: CVS and unicode

[Arno Schuring]

> 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