On 29.02.2016 20:45, Vincent Lefevre wrote:
>>> The problem is that it is too easy to create files with a name using
>>> invalid UTF-8 sequences
>> File names on disk DO NOT have to be represented in UTF-8. They do have
>> to be represented in consistently with the current locale settings.
> which must in practice be UTF-8. Otherwise one gets failures sooner
> or later.
I'm just going to say "nonsense" to that without much further
discussion. The encoding "must" be consistent, but by no means must it
>> A fairly plausible cause for getting the wrong representation is
>> changing the locale for the duration of a script invocation. Another
>> plausible way is to create files based on the contents of some script,
>> which are not encoded the as expected by the current locale.
> However Subversion doesn't handle that (BTW it would be much better
> to remember the expected locale by storing it in the .svn directory
> rather than giving obscure error messages: if it did, Subversion
> would know that the user was using an incorrect locale without any
And if the user changes the locale for valid reasons, the Subversion
working copy would break in a different way.
> Currently you can't avoid the problem: if the user has used UTF-8
> then runs Subversion under ISO-8859-1 locales, the "misconfiguration"
> is not detected, and "svn up" can yield corrupt a working copy as
> shown in the past. Subversion should remember the locale that was
> used initially to avoid such a problem.
Well? This issue isn't limited to Subversion; most applications with
fail at some point once you start playing games with the locale and/or
filename encoding. That's why both Windows and OS X mandate one of the
Unicode representations for filenames.
You might as well say that Unix (Linux) is broken and should be fixed
(with which I'd heartily agree, but that's water under the bridge).
>> I'd really, really strongly suggest not to make such a thing the
>> default in Subversion.
> Then fix Subversion.
Received on 2016-02-29 20:57:23 CET