Re[2]: [lmi] Should we restrict cvs files to ASCII?

[Vadim Zeitlin]

On Tue, 17 Apr 2007 17:57:49 +0200 Evgeniy Tarassov <address@hidden> wrote:

ET> Vadim has asked me to create a patch involving non-ASCII characters
ET> and to upload it to CodeStriker to test its behavior.

 Thanks for testing!

 Note that we can see the changes from ISO8859-1 to UTF-8: the UTF-8
symbols appear correctly while the ISO8859-1 ones appear as '?'. So this is
not ideal but at least the changes can be seen.

ET> - CodeStriker recieves text files as input and it cannot correctly
ET> determine the patch-file encoding, therefor it uses utf8 to handle
ET> unicode and to stay backward compatible with ASCII-embrased projects.

 And this behaviour is clearly by design. So all we could do would be to
[ask Codestriker developers to] allow to specify per-project encoding. It
probably shouldn't be very difficult to do...

ET> - In my IDE when i create a CVS repository link i can specify the
ET> encoding of the repository.

 The encoding is not a cvs property, cvs treats all files as arrays of
bytes. The IDE probably just uses it in its text editor.

ET> I suspect that 'cvs protocol' has a hardcoded utf8 encoding for text files.

 No, not at all, it knows nothing about encodings.

ET> Otherwise any patch file containing non-ASCII characters will depend
ET> on the way it was created ('cvs diff' will produce utf8 encoded file,
ET> 'diff' will produce ISO-8859-1 (native lmi encoding)).

 Again, no, cvs diff doesn't produce UTF-8 encoded files, the output will
contain UTF-8 characters if and only if the input file had them.


 Anyhow, I think we can still standardize on using ISO8859-1 knowing that
while it can result in unreadable characters in the Codestriker it should
rarely be a problem as non 7-bit characters occur only rarely in LMI.

 Regards,
VZ