Cannot do git-svn fetch behind proxy

Question

I'm trying to mirror a svn repo using git-svn.

I'm doing

git svn clone http://worldwind31.arc.nasa.gov/svn/trunk/WorldWind

And I'm getting

Initialized empty Git repository in f:/gstest/WorldWind/.git/
RA layer request failed: PROPFIND request failed on '/svn/trunk/WorldWind': PROPFIND of '/svn/trunk/WorldWind': could not connect to server (http://worldwind31.arc.nasa.gov) at /usr/lib/perl5/site_perl/Git/SVN.pm line 148

If I do the same on another computer that isn't within the proxy it's ok.

I'm on a win7, and I've set $HTTP_PROXY, http.proxy (the global one in git) and $HOME/AppData/Roaming/Subversion/servers to the correct proxy.

Doing svn checkout [repo adress] in a shell works. Doing wget [repo adress] in a shell works. But not git svn clone [repo adress]

Any ideas? Most of the questions I've found on this points me to the Subversion/servers file, but now I've edited that one and the problem is still there... :/

Almonry

Answer 1

I had the exact same problem.

And the solution is finding the correct Subversion configuration directory. At least in my case the native svn.exe uses the file C:\Users\MYUSER\AppData\Roaming\Subversion\servers, but git-svn uses ~/.subversion/servers. And I mean this path ~/.subversion/servers in the Git Bash shell, where ~ is expanded to the right location. Edit ~/.subversion/servers the same way as the other one used by svn.exe and then git svn clone should work.

In short, the key is finding the right configuration file to edit, as you may have multiple of them in Windows.

Canadianism

This solved my problem, and I feel pretty stupid for not recognizing it at first... I searched for all files called 'servers' on local hard drives and only found one. So that was the one I edited. (C:\Users\MYUSER\AppData\Roaming\Subversion\servers) However, at my workplace the home catalogue is mapped to a network drive too. And there was a M:\.subversion\servers file that I didn't find the first time.... :( when I edited that one git svn worked like a charm. Thanks! – Almonry

Answer 2

To get svn to work behind a proxy on linux, update the file ~/.subversion/servers with the proxy details.

[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
http-proxy-host = YOURPROXY.com
http-proxy-port = YOURPORT
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# http-auth-types = basic;digest;negotiate
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem

I guess there's a similar configuration on windows...

Acotyledon

Yep i think it should be equivalent to C:\Users[me]\AppData\Roaming\Subversion\servers, at least the file looks the same. And i've edited it, but it doesn't work anyway :/ – Almonry

That's a shame. Sorry I couldn't help you solve your problem. What does google tell you? – Acotyledon

Thanks for the effort! Google tells me the same pretty much, change in .subversion/servers... Is there any way to see what proxy settings are actually used with git-svn? Perhaps some kind of verbose setting to either 'git svn clone' or 'git svn fetch'? – Almonry

Key things to remember on Windows: 1) Update the section [global] not [group1] or [othergroup] etc... 2) Update both C:\Users\USERACCOUNTNAME\.subversion and C:\Users\local_admin\AppData\Roaming\Subversion (which will work on Windows 7 at least). – Pinna

If the above doesn't work, make sure you're in the [global] section and not the [groups] section :-) – Condescendence

It works OK under Windows 7 with the latest git-for-windows(git version 2.21.0.windows.1). Tod Thomson's method is correct. I think someone can add to Fredrik Pihl's answers. – Atavism

To me seems like C:\Users\USERACCOUNTNAME\.subversion is the correct location to edit. Works like a charm, thanks for tip! – Firedrake

Answer 3

Usually, the environment variables alone:

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

are enough for git or git-svn to work properly.

But what gets me is the exact url to use.
For instance:

• HTTP_PROXY=wwww.myproxy.company:8080 won't work, but
• HTTP_PROXY=http://wwww.myproxy.company:8080 will work.

Use the same for HTTPS_PROXY, meaning the same http address (I tried first putting an https url for the HTTPS_PROXY, but that is not how it works)

Of course, if you need to authenticate, you can (at least for testing purposes) add your login/passname in it:

HTTP_PROXY=http://myLogin:[email protected]:8080

And it helps setting the NO_PROXY one too: localhost,*.company.

---

So the main point behind this answer is "double check the exact url you are using" (and test it with a simple curl http://www.google.com, or with wget, either from the msysgit package or from Gnu On Windows)

Quincentenary

Interesting, I'll try this on monday! I think I've entered HTTP_PROXY without 'http://' – Almonry

No luck... After including 'http://' in the proxy settings the problem remains. I can do wget google.com, however when I do it still shows my proxy without 'http://'. I wonder if it trunkates away the 'http://' or if it's still without it... :/ If I do wget on the adress of the svn repo I can connect to it too. – Almonry

@Almonry You mention it still shows my proxy without 'http://'. Can you detail a bit what shows that proxy without http, and how it is displayed? If I understand correctly, now the wget works, but the svn operations involving net connections still don't work, is that correct? – Quincentenary

when I do wget, I get a line in the result like; 'looking up myproxy.com... [ip number]. (without http://) wget [repo adress] works, doing 'svn checkout [repo adress]' works, but not 'git svn clone [repo adress]' – Almonry

@Almonry ok. The output is normal then (for wget). – Quincentenary

@Almonry Now git svnshould use the perl module LWP::UserAgent for proxy management, and it mentions: "On systems with case insensitive environment variables there exists a name clash between the CGI environment variables and the HTTP_PROXY environment variable normally picked up by env_proxy(). Because of this HTTP_PROXY is not honored for CGI scripts. The CGI_HTTP_PROXY environment variable can be used instead." Can you try playing with the case, or setting CGI_HTTP_PROXY just in case it would work? – Quincentenary

i have tried all cases and tried setting CGI_HTTP_PROXY too, no luck... i'm not very fluent in perl but i tried a small script that tried to access the svn-repo, and it worked when i had HTTP_PROXY with http://, but not without. i got the proxy settings with env_proxy(). so with these env_proxy() settings i'm at least able to access the server in a perl script, but git-svn i still not working... :/ – Almonry

@Almonry that means git-svn doesn't take into account those environment variables. What version of git-svn are we talking about? Maybe it is possible to modify that perl env_proxy() setting globally, in order for the perl script from git-svn to pick it up? – Quincentenary

@Almonry Maybe it is possible to modify that perl env_proxy() setting globally, in order for the perl script from git-svn to pick it up? – Quincentenary

Answer 4

Have a look in C:\Users\YOU\.subversion\servers for the settings. You're looking for something inside this file like...

[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
http-proxy-host = 127.0.0.1
http-proxy-port = 3128

... These settings are for CNTLM. Uncomment the lines I have uncommented above & put your own details in. There are fields for passwords etc. Fixed it for me getting stuff from Sourceforge. Yeah, Sourceforge is still there.

Also, CNTLM is great for getting through NTLM, forefront etc. Run Fiddler2 & set the rules to "Automatically Authenticate" to true to pick up any auth that CNTLM misses. Chrome updates are one thing that Fiddler fixes for me.

Thermophone

Answer 5

For me the solution was just to change url in config. Because I wasn't able to access the existing one. To check I simply accessed the repo url using my browser. In case of using forbidden url I got '403 Forbidden'.

Backscratcher