* Garrett Rooney <email@example.com> wrote:
> > So whether the users of a repository (httpd or svnserve) may use the full
> > unicode range for their files depends on the locale of the server? That feels
> > just wrong ;-) I don't see how there are command line confusings...
> Well, yes and no. For all the internals of the repository it doesn't
> matter at all what the the locale of the server is, but as soon as you
> need to pass that data as part of the command line of an external
> program like a hook script it does matter.
Just in terms of documentation. IMHO.
> > As long as one references files enclosed in the filesystem no translation
> > should occur at all. It's just unicode (in utf-8 format). The only part of
> > the subversion system which should deal with filename recodings of reposiory
> > stored path should be a client.
> I'm really not sure I agree, for an external program on a system
> running in a particular locale I'd be REALLY surprised to get data
> passed in via the command line that shows up in some arbitrary
> encoding, it should really show up in the native encoding IMO. The
> fact that httpd choses to ignore the system's locale and thus has a
> native encoding that only allows 7 bit ascii is the real bug here.
I see the hook system as part of the repository internals. If you mix it with
locales (e.g. start svnserve in a latin-1 locale and have paths containing
japanese chars), you end up with an unusable repository (or let's call it
not fully functional) for no good reason. I mean, there's in the middle of a
unicode aware system a transition to a non-aware system and back (if you
happen to lookup the path in the repository from inside of the hook script).
By the way, at least in the past the locale information wasn't passed to the
hook scripts at all (I don't know if this was fixed already), so the hook
scripts could/can not determine the encoding anyway. Passing UTF-8 encoded
filenames is good and clear choice then.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 19 21:36:03 2006