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

Re: [SVN-DEV] Re: [Dale Thatcher <subversion@dalethatcher.com>] Posting to the list

From: Branko Čibej <brane_at_xbc.nu>
Date: 2001-09-15 00:07:30 CEST

C. Scott Ananian wrote:

>On Thu, 13 Sep 2001, Branko Cibej wrote:
>>And so do the getenvs. Use a comand-line option instead.
>>-1 (veto) on having Subversion's behaviour depend on environment variables.
>presumably the proxy option will either be stored in the working copy
Hm. Sometimes you need different proxies to get to different servers.
Using an env var would be bad in such (probably rare) cases.

> or
>settable in a .svnrc file somewhere? I don't think repeatedly typing
>'--http-proxy=longurlhere' on the command-line is going to win us many
>friends. The vote for the http_proxy environment variable is that *this
>is how most applications behave* -- the perl HTTP modules, wget, dselect,
>etc -- and the system administrator can set this in the user's default
>environment to have things 'just work' for the users. Administering a
>proxy is made *much much much* more difficult if every user must manually
>set up every application by themselves. Surely this isn't the intent?
Of course not. There will be a global /etc/svn.conf file, and a ~/.svnrc
file, where this option can be defaulted. In the meantime, shell aliases
(perhaps in global config files) are a good alternative.

Relying on environment variables creates a maintenance nightmare,
especially since not all variables are "standard" on all systems. We
can't avoid honoring truly standard variables like LANG and LC_*
(although we do our best with --locale), but IMO should avoid others.
Putting options in a .rc file at least doesn't pollute the env space for
other apps.

Then again, maybe I'm paranoid.

<rant>Why can't people use transparent proxies?</rant>

Brane �ibej   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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

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