git svn не обов'язково використовує HTTP-проксі Git

git fetch виконується успішно, але git svn fetch не може дістатися до сервера. Попри спільний префікс команди, друга операція спілкується з репозиторієм Subversion через інший клієнтський стек.

Не припускайте, що нативний запис http.proxy у Git налаштовує це з'єднання Subversion. Знайдіть конфігурацію часу виконання, яку використовують бібліотеки Subversion у середовищі, де працює git svn.

Конфігурація servers у Subversion може містити:

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

Ім'я хоста й порт — окремі значення; список HTTP-проксі пропонує кандидатів для дозволених публічних маршрутів Subversion. Поля облікового запису проксі відокремлені від облікових даних репозиторію. Налаштування груп серверів Subversion зіставляються з іменами хостів, а не з довільними шляхами репозиторію. Сприймайте їх як інтерфейс Subversion, а не як альтернативне написання URL проксі Git.

У Windows несподіванкою може стати шлях

Нативний виконуваний файл Subversion і встановлення git svn можуть використовувати різні середовища й по-різному тлумачити домашній каталог. Редагування конфігурації, яку використовує svn.exe, не доводить, що виклик git svn її прочитав.

Запишіть, який виконуваний файл і яке бібліотечне середовище задіяні, потім визначте їхнє фактичне розташування конфігурації. Уникайте копіювання шляху одного користувача до скрипту для всієї машини.

Тримайте облікові записи окремо

Проксі може автентифікувати вихідне з'єднання. Репозиторій Subversion після цього може вимагати інший обліковий запис. HTTP 407 і помилка авторизації репозиторію описують різні етапи.

Якщо URL або маршрут заборонено політикою, використовуйте схвалену кінцеву точку та порядок доступу. Відкриття веб-інтерфейсу репозиторію в браузері — лише часткове порівняння: він може використовувати інший обліковий запис, сховище конфігурації чи маршрут. Мета — успішна операція Subversion через передбаченого посередника, а не просто успішний звичайний запит веб-сторінки.