On 7/17/07, Lucian Adrian Grijincu <[EMAIL PROTECTED]> wrote:
On 7/17/07, Erik Huelsmann <[EMAIL PROTECTED]> wrote:
> No, I can't confirm: I'm trying to find out why Subversion is the only
> app complaining there's no locale set when interacting with the
> filesystem while the rest of the world seems perfectly fine with
> reading UTF-8 filenames. [But I don't own a Mac myself either, though
> I sure can find someone to test for me, later today.]
>
> Subversion generates an error when there's no locale setting *and* APR
> returns APR_FILEPATH_ENCODING_LOCALE, but everybody kept on insisting
> there's no reason, because there's no locale involved in OS X file
> names. (Presenting to the user, maybe, but not for storing on disk.)
>
Hmm, this sounds like an error of interpreting things from
subversion's point of view.
Why? Subversion shouldn't need to know about this Darwin convention.
That's why we depend on APR. If APR tells us to check the locale, we
do. If it tells us we can write UTF8, we do and since we're UTF8
internally, we don't need to do character translation (meaning we
don't need the locale system to be initialized in that case).
One thing you could try is to see whether compiling APR to return
APR_FILEPATH_ENCODING_UTF8 fixes your problem or not.
Oh, that will fix the problem, because it will not try character
translation if it gets _UTF8.
*IF* UTF8 is the only locale on Macs, APR_FILEPATH_ENCODING_UTF8 seems
like the right value to return, because it's more explicit than
APR_FILEPATH_ENCODING_LOCALE, but then again, I haven't looked to see
how code interacts with these values.
Well, I was arguing that if the filepath encoding is independent of
the locale, returning APR_FILEPATH_ENCODING_LOCALE would be the wrong
thing to return.
I'll try to get in contact with someone with experience developing on
OS X and I'll get back to this discussion.
bye,
Erik.
