git svn 不一定使用 Git 的 HTTP 代理

git svn 通过另一套客户端栈与 Subversion 通信。请定位该环境实际读取的 Subversion 配置。

git fetch 能成功，但 git svn fetch 无法连上服务器。尽管命令前缀相同，后一个操作是通过另一套客户端栈与 Subversion 仓库通信的。

不要以为 Git 原生的 http.proxy 条目会配置那条 Subversion 连接。请定位运行 git svn 的环境中 Subversion 库实际使用的运行时配置。

Subversion 的 servers 配置可以包含：

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

主机名和端口是两个独立的值；HTTP 代理列表为被允许的公共 Subversion 路由提供候选。代理账号字段与仓库凭据是分开的。Subversion 服务器组设置匹配的是主机名，而不是任意仓库路径。请把它们当作 Subversion 的接口，而不是 Git 代理 URL 的另一种写法。

在 Windows 上，路径可能就是那个意外

原生 Subversion 可执行文件与 git svn 安装可能使用不同的环境，对主目录的解读也不同。修改 svn.exe 所使用的配置，并不能证明 git svn 调用读过它。

记录涉及哪个可执行文件和哪套库环境，然后确定它们实际生效的配置位置。避免把某个用户的路径复制进整台机器的脚本。

把账号分开

代理可能负责验证对外连接。Subversion 仓库随后可能要求另一个账号。HTTP 407 与仓库授权错误描述的是不同阶段。

如果策略拒绝该 URL 或路由，请使用获批的端点和访问安排。浏览器能打开仓库的 Web 界面只是部分可比：它可能使用另一个账号、另一份配置存储或另一条路由。目标是让 Subversion 操作通过预期的中间环节成功，而不只是普通网页请求成功。

相关文章