On 30 May 2002, Karl Fogel wrote:
> How reliable it is to use locale to determine the source format of the
> conversion (or whatever method we're going to use), though? For
> example, my locale indicates nothing about Chinese editing, but
> sometimes I write text in one of the various char encodings that
> supports Chinese characters. If I were to do that in a log message on
> some project, my log message would get all messed up. In such a case,
> leaving it alone would be better, because some tools that can
> heuristically determine the charset -- *if* they have the original
> data to work with. If the data is there, one can guess at the charset
> if necessary. If the data is destroyed by a misconversion, then it's
> gone. That's why I feel it's better to leave it alone.
</lurk>
I think that we should keep the log messages in UTF-8 for the reasons
mentioned by Marcus and others. (Mainly, out-of-band policy information
makes writing client software harder.)
In order to solve the "but which charset am I using", I think we should
offer --charset= and config-file defaults which take precedence over
LC_TYPE. The config-file defaults should control separately the charset
used for recoding local filenames, and the charset used for log
messages.
(Actually, the idea of recoding UTF-8 filenames seems pretty weird to
me, but I've never used non-ascii filenames so I can't speak from
experience. But what happens if your filename gets recoded when a shell
script which refers to it doesn't? At least with log-message recoding
filenames in the message will match the checked out filenames.)
-David Mankin
<lurk>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:15:05 2002