Re: Check-out fails with LANG=C

On 2013-07-31 23:32:57 +0200, Branko Čibej wrote:
> On 31.07.2013 15:49, Vincent Lefevre wrote:
> > No, even "LC_ALL=en_US.UTF-8 cp" doesn't have any effect.
>
> What do you mean by "doesn't have any effect"?

The output is the same, as without the "LC_ALL=en_US.UTF-8": still
in French. Except in POSIX locales, the language is not controlled
by the LC_* environment variables with the glibc (at the top level).

> > FYI, some other VCS such as git or Mercurial don't have such problems
> > of broken working copies if the locale changes, at least under Unix,
> > probably because they regard a filename just as a sequence of bytes.
> > The byte-sequence interpretation under Unix is a problem introduced by
> > Subversion, currently out of the scope of the POSIX API.
>
> Those version control systems have a massive problem with
> interoperability across platforms where file name encodings differ and
> file names are anything but the ASCII subset. Subversion has mostly
> avoided that problem for the last 10+ years.

Such problems are avoided with some drawbacks. But under Unix, there
are no problems at all.

> If you want to propose a different way of solving it, please stop
> telling me that we should change everything about file name translation
> and instead post to the dev@ list and propose a solution that will work,
> backward-compatibly, without breaking current working copies. And note
> that "store the encoding in the working copy metadata" is not such a
> solution (see above under "works" and "backward-compatibly").

There's absolutely no reasons why it wouldn't work. And it's backward
compatible with existing working copies because the encoding would be
stored only on new checkouts (optionally) or when the user explicitly
requests it.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)