© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Jelmer Vernooij wrote:
> Wrapping all bzr-svn calls by setlocale() may be the best solution here.
Ugly, as setlocale is not guaranteed to be thread-safe, and can be quite inefficient as well.
Quoting from http://
"It is generally a bad idea to call setlocale() in some library routine, since as a side effect it affects the entire program. Saving and restoring it is almost as bad: it is expensive and affects other threads that happen to run before the settings have been restored."
> Unless there's some other way to tell apr the encoding of everything it
> receives is UTF-8...
I can see no alternative route through the sequence of library calls. One possibility might be some interposter library that overrides one of these functions, in order to relay it to the original implementation unless the current thread requested a fixed return value for the next call. Ugly, probably difficult to get right, and I guess none too portable either.
Two more options, both of which I would deem superior to those mentioned above:
Leave it to bzr. I have hopes to get some setlocale support merged soon: http://
I'm against ugly code in one project just to work around the deficiencies of code in another project, as this tends to make code quite unreadable. So you could try to get that fix backported in the next bzr 1.5 release, if there will be such a thing, and otherwise wait for 1.6.
Have bzr-svn modify bzrlib itself. As you can see, the fix above contains modifications to three functions, and a bit of top level code. Maybe bzr-svn can introduce this fix into bzr versions that don't provide it themselves. I don't know enough Python to be sure, but I would have thought that it should be possible to redefine these functions. Either there is a reliable way to get the source and apply the patch, or you rely on the current implementation being appropriate for all previous implementations as well, or you have a list of different implementations to choose from for different versions of bzr. The top level code could be executed during bzr-svn initialization, under the condition that the locale is still unset (i.e. set to "C"), the bzr version is known not to contain the fix, and bzrlib was actually loaded by the bzr command line tool, to stay consistent with a fix in bzr.