Fazekas Miklós <boga@mac.com> writes:
> I vote for UTF-8. If you don't recommend a specific encoding, all tools have
> deal with all kinds of encoding to be usefull for everyone. (When going with
> UTF8, UFT8 <-> local converson is enough.)
Yeah, sigh, that's true. So the inconvenience of storing metadata (to
indicate the log message encoding) becomes not just the extra property
and consequent extra parameter being passed around everywhere, but
also the higher burden on all clients receiving log messages from the
repository.
The convincing thing about this argument is that there are far more
consumers of log messages than producers. Only committing clients
would ever need to recode log messages. But lots of read-only
browsing software will need to read log messages.
Given
- The ability to change log messages post-facto (which lowers the
penalty for bad guesses, as Greg Stein pointed out), and
- The ability to specify the log message encoding at "svn commit"
time, so the user can guarantee a perfect conversion to UTF-8 (an
ability which we don't have now but easily could, by adding a new
command-line option and a config option), ...
...I think the risks of lossy mis-encoding are getting pretty low.
People might occasionally get burned, but they'll learn. One can
always rewrite a log message based on the diff, anyway. And we can
make sure that the Emacs svn integration, for example, passes along
its knowledge of the log message's encoding when it invokes the svn
subprocess.
I hate the thought of munging user data in any way, but interop among
log messages is worth encouraging. With the run-time option to
override locale, I'm +1 on canonicalizing log messages as UTF-8.
[I'll take care of the Emacs support, when the time comes, too :-) ].
-K
---------------------------------------------------------------------
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:10:56 2002