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