git svn Doesn't Necessarily Use Git's HTTP Proxy

git fetch succeeds, but git svn fetch cannot reach the server. Despite the shared command prefix, the latter operation talks to a Subversion repository through another client stack.

Do not assume a native Git http.proxy entry configures that Subversion connection. Locate the runtime configuration used by the Subversion libraries in the environment running git svn.

Subversion's servers configuration can contain:

[global]
http-proxy-host = proxy.example
http-proxy-port = 8080

The hostname and port are separate values; the HTTP proxy list supplies candidates for permitted public Subversion routes. Proxy account fields are separate from repository credentials. Subversion server-group settings match hostnames, not arbitrary repository paths. Treat those as Subversion's interface, not as an alternative spelling of Git's proxy URL.

On Windows, the path can be the surprise

A native Subversion executable and a git svn installation can use different environments and different home-directory interpretations. Editing the configuration used by svn.exe is not evidence that the git svn invocation read it.

Record which executable and library environment are involved, then identify their effective configuration location. Avoid copying one user's path into a machine-wide script.

Keep the accounts separate

The proxy may authenticate the outward connection. The Subversion repository can require another account afterward. An HTTP 407 and a repository authorization error describe different stages.

If the URL or route is denied by policy, use the approved endpoint and access arrangement. A browser opening the repository's web interface is only a partial comparison: it may use another account, configuration store, or route. The goal is a successful Subversion operation through the intended intermediary, not merely a successful ordinary web-page request.