On Thu, Sep 13, 2012 at 4:50 PM, Josh Triplett <josh_at_joshtriplett.org> wrote:
> On Thu, Sep 13, 2012 at 08:03:06AM -0400, C. Michael Pilato wrote:
...
>> - While your approach was the super simple one to take, how do we feel about
>> the fact that this would cause all programs which linked against
>> Subversion's libs to start noticing those environment variables which are
>> really kind meant to be specific to just the command-line clients. In the
>> past, I (and others) have gone on record against such things. Perhaps a
>> better approach would be for 'svn' -- or one of the common svn_cmdline_*
>> functions in libsvn_subr -- to parse the env variables and use the results
>> to override the parsed runtime configuration values in the svn_config_t
>> structures that get passed all over the place. I dunno.
>
> Why should only the command-line clients notice those environment
> variables? If someone has http_proxy set, and runs some graphical
> subversion client using libsvn, that client ought to use the proxy as
> well. I'd suggest that libsvn should always respect system proxy
> settings, rather than forcing the caller to do extra (duplicate) work to
> parse and set the proxy.
I'm not an expert in proxy stuff, but can you also set
proxy-exceptions, and a proxy-username and password via those
environment variables (or setting a proxy configuration file (pac))?
If you go the route of reading the environment, I think you should
also be able to do those things.
In our company, I have to connect directly to internal servers (like
our svn repository), and only for external services go through the
proxy. So there is a nice (and complex) pac file set up by our IT
department for this. For svn usage, I use the 'grouping' feature of
the 'servers' configuration file, to specify a proxy only for some
external servers (e.g. *.googlecode.com and such). Of course, if svn
would be able to fully read and abide by the system proxy
configuration (i.e. the proxy pac file), that would be great :-).
--
Johan
Received on 2012-09-14 13:23:02 CEST