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 操作の成功であり、通常の Web ページ要求が成功することだけではありません。

関連記事