On Wed, Jun 22, 2011 at 07:09:22PM +0200, Andreas Krey wrote:
> In my opinion it would be saner nowadays to assume file names to
> be in utf8 and warn if they are not, and use the setting in LANG
> for console I/O only.
This strategy may work well for applications starting out today.
but it won't work for Subversion.
Not all operating systems have switched to UTF-8 as the default
character set yet. ASCII is still the only encoding that works
everywhere out of the box (especially on the console!).
E.g. Debian switched to UTF-8 by default for the Etch release in 2008.
http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.en.html
Many unixy systems that aren't Linux have not switched to UTF-8 by
default, and it is possible that some never will.
Subversion is supposed to be portable across all these platforms and
more.
Subversion was founded in 2000 and the first 1.0 release was in 2004,
which all subsequent 1.x releases need to stay compatible with (so
we cannot just change the default behaviour now).
UTF-8 is older than 2003, but received its most recent update in
RFC 3629 which is from 2003. It was fairly new stuff when Subversion
was originally developed, far from being the default on many systems.
Back in 2003 you couldn't just write UTF-8 to the screen or create
UTF-8 filenames and expect this to work well by default on all platforms.
I agree that locales aren't the ideal solution to this problem.
But at least they are standardized by POSIX and can be expected
to behave the same way everywhere. And they allow Subversion users
to say "yes, my system supports UTF-8, please use it".
The best solution would be a standardised way of specifying
filename encoding that works the same on all filesytem types in
all operating systems. Alas, that doesn't exist :(
I don't think the current solution is perfect. But it's a good
compromise given the circumstances.
Received on 2011-06-22 19:34:51 CEST