You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2001/09/14 22:07:30 UTC

Re: [SVN-DEV] Re: [Dale Thatcher ] Posting to the list

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   <br...@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

Http proxy patch [Was: Re: blah... blah...

Posted by Dale Thatcher <su...@dalethatcher.com>.
Here are the changes I propose to make:

1) Add a proxy callback that will be called with the repos URL.  It returns a
proxy host and port or null.  This would allow clients to make more
complicated decisions on which proxy to use.  Therefore allowing them to
behave in the same way as web browsers with a proxy for most and a list of
exceptions.  The client would be responsible for choosing the appropriate
proxy for each situation.

2) Make a default callback that returns NULL.

3) Add callbacks for proxy username and password.

Comments?

thanks,

- Dale Thatcher

On Sat, Sep 15, 2001 at 12:07:30AM +0200, Branko Cibej wrote:
> 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 Cibej   <br...@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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org