[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "Can't recode string" again...

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2006-01-06 22:47:43 CET

>>>>> "Ryan" == Ryan Schmidt <subversion-2006Q1@ryandesign.com> writes:

 Ryan> On Jan 6, 2006, at 20:40, Paul Koning wrote:

>> ... with one exception, of course: if you run any client type apps
>> at the server (in hook scripts) then those naturally would depend
>> on some locale. That's actually somewhat ugly. Ideally the hook
>> script would inherit the locale setting of the client whose
>> request triggers the hook. Enhancement?

 Ryan> Why is that ideal? If I have some people committing files with
 Ryan> ISO-8859-1 locales and others committing with UTF-8 locales and
 Ryan> everything gets to the repository correctly, then in my hook
 Ryan> script I want to send an email, and I definitely need to know
 Ryan> when programming the hook what charset information to put in
 Ryan> the email headers (and it's gonna be UTF-8). So I definitely
 Ryan> want my svn client commands to always behave with the same
 Ryan> locale in my hook scripts. Not whatever locale the committer
 Ryan> might have used.

True.

If you're generating a string that's going to third parties, that is
true.

If you're generating a string that goes back to the committer (for
example an error message) you'd want to use the locale of the
committer.

So the hook script should have available to it the locale of the
committer; that allows it to do things in that locale if that is the
right thing to do, and it also allows it to use some other locale.

      paul

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 6 22:50:49 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.