On Thu, Sep 13, 2012 at 4:50 PM, Josh Triplett <j...@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