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 через предполагаемого посредника, а не просто успешный обычный запрос веб-страницы.

Похожие статьи