[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC/PATCH] commit messages not 8-bit compatible

From: David Mankin <mankin_at_ants.com>
Date: 2002-05-31 02:07:34 CEST

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.

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

(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

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

This is an archived mail posted to the Subversion Dev mailing list.