PORT/work/.home/.subversion and proxy access

[mthomas+macports@…]

When attempting to "port fetch netpbm", I kept getting an error that svn was unable to contact the server. (Relevant part of log attached.)

I could not understand what was happening because running the svn command from the prompt worked as expected. (My install of ports are installed as a normal user account, not using sudo).

Since I access the internet via a proxy, I suspected that the svn command that "port" was running was not seeing my proxy settings, despite having set the proxy in my environment, in the /opt/local/etc/macports/macports.conf file, and in ~/.subversion/server.

The issue appears to be that the temporary subversion configuration files created in .../netpbm/work/.home/.subversion/server do not include the proxy setting. When I edited that file to include my proxy setting, I was able to fetch the netpbm sources.

It took me a while to diagnose the problem. Had the debugging output included some indication that a fake home directory had been created while running subversion, the issue would have been easier to diagnose.

[ryandesign (Ryan Carsten Schmidt)]

I wonder how we should best fix this.

I don't think we should be copying the user's .subversion directory because it might have customizations we don't want, or might be for the wrong version of Subversion.

Perhaps we could take the proxy setting from macports.conf and insert it into the appropriate file within the .subversion directory when we create it.

Would this issue affect other fetch methods as well? What about git, hg, bzr or cvs?

[danielluke (Daniel J. Luke)]

Replying to ryandesign@…:

I wonder how we should best fix this.

by deprecating using fetch types that pull from revision control systems?

If we made it 'easy' for maintainers to put a tar.bz2 on the macports mirrors, there wouldn't be any reason to have ports in the main repo use them (but it's probably still a 'nice' feature for people doing initial work on ports, or for ports in their local repos).

Unfortuantely subversion doesn't support the http_proxy environment variable. We could probably patch base to pass an appropriate set of --config-option arguments for subversion, I don't know about the others...