Revining this old thread.
On Mon, Jan 04, 2010 at 08:59:50AM -0500, C. Michael Pilato wrote:
> We have the ability technically to pass UTF-8 strings to the hooks. Add
> flags down the code stack towards svn_io_start_cmd() that say "Don't convert
> the parameters", or somesuch. But is it the right thing to do? On the plus
> side, it relieves us of any concern with locale handling in these parts.
> But this puts the conversion burden on each and every hook script. And keep
> in mind that it's not just the input to the hooks at stake here -- we also
> need to consider the output from them (stdout and stderr messaging). Do we
> then also expect the hooks to generate UTF-8 output instead of output in the
> system's preferred locale (so we can package it up correctly for
> transmission back to the client)?
I think this is what we'll need to expect people to do.
How can hook scripts even tell what the native encoding is?
They cannot know because their environment is empty.
Given that httpd is avoiding setlocale() we're pretty much left without
locale support in mod_dav_svn. No locale support means that there is no
concept of a "native" character set. All you've got without locales
is the standard character set of the C programming language (ASCII),
and the ability to use any user-specified character sets and convert
between them using iconv().
I've attached two patches to issue #2487 which implement this approach.
I don't really like the use of an environment variable to pass
information from mod_dav_svn to libsvn_repos. But it cannot do much
harm and might also come in handy in other situations, so why not...
Received on 2012-01-31 20:53:33 CET