Saturday, November 18, 2006

Disabilng subversion localization.

I had a hard time figuring how to disable svn localization features, so this post is just here in the hope that it can help the next person who encounters this problem. Its very simple, actually. Subversion obeys traditional Unix internationalization environment variables even when running on other operating systems, so one can just set the LC_ALL env variable to "C" (without the quotations marks) and the console tools will work just as installed on an english language system.

Why did I want to do this? One reason is that the locale handling is broken by default on Windows, but its not hard to fix this (just set the APR_ICONV_PATH environment variable to the \iconv directory on your svn installation). I did it because some build scripts found in the wild work by parsing svn output and localization obviously screws them up.

3 comments:

Francisco said...

Cool! I was hidden the text-only version of subversion because of that problem. Now I can tell some programmers who never use the command prompt how to use the command prompt version of subversion... well, you got it.

tautologico said...

Não usei muito subversion, mas tem outros posts interessantes por aqui. Achei o endereço pela lista da linguagem Scala, e eu também postei um pouco sobre ela há um tempo (mas sem código):
http://realpar.blogspot.com/2006/01/como-programar-em-java.html

tautologico said...

Eu acho Scala muito legal como "ponto de entrada" para a programação funcional para gente que só conhece Java, e é bom que ela esteja ganhando visibilidade, assim como a linguagem F# na plataforma .NET. São as duas linguagens que eu atualmente acho mais interessantes para as duas plataformas.

Com relação às provas de programa, eu concordo com o problema da especificação e até comentei isso alguns posts depois. Uma idéia é que a especificação pode ser mais simples, e portanto mais fácil de verificar. O problema, realmente, é que ainda não temos a teoria necessária para fazer provas de programa realistas, na maioria dos casos. Eu não acho que seja necessário usar provas sempre, para programas inteiros, mas em alguns pontos críticos de programas importantes, pode ser uma boa pedida. Sistemas de tipos avançados e técnicas para desenvolver a própria prova em conjunto com o programa são algumas direções em que isso poderá se tornar prático no futuro.