git svn niekoniecznie używa HTTP-proxy'ego Git

git fetch się udaje, ale git svn fetch nie może dotrzeć do serwera. Mimo wspólnego prefiksu polecenia druga operacja rozmawia z repozytorium Subversion przez inny stos klienta.

Nie zakładaj, że natywny wpis http.proxy Git konfiguruje to połączenie Subversion. Znajdź konfigurację czasu działania używaną przez biblioteki Subversion w środowisku, w którym działa git svn.

Konfiguracja servers Subversion może zawierać:

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

Nazwa hosta i port to osobne wartości; lista proxy HTTP dostarcza kandydatów do dozwolonych publicznych tras Subversion. Pola konta proxy są oddzielone od danych logowania repozytorium. Ustawienia grup serwerów Subversion pasują do nazw hostów, a nie do dowolnych ścieżek repozytorium. Traktuj je jako interfejs Subversion, a nie alternatywną pisownię adresu proxy Git.

W Windows zaskoczeniem może być ścieżka

Natywny plik wykonywalny Subversion i instalacja git svn mogą używać różnych środowisk i różnych interpretacji katalogu domowego. Edycja konfiguracji używanej przez svn.exe nie dowodzi, że wywołanie git svn ją odczytało.

Zapisz, który plik wykonywalny i które środowisko bibliotek są zaangażowane, a następnie ustal ich faktyczną lokalizację konfiguracji. Unikaj kopiowania ścieżki jednego użytkownika do skryptu dla całej maszyny.

Trzymaj konta osobno

Proxy może uwierzytelnić połączenie wychodzące. Repozytorium Subversion może następnie wymagać innego konta. HTTP 407 i błąd autoryzacji repozytorium opisują różne etapy.

Jeśli zasady odmawiają dostępu do adresu URL lub trasy, użyj zatwierdzonego punktu końcowego i ustalonego sposobu dostępu. Otwarcie interfejsu webowego repozytorium w przeglądarce to tylko częściowe porównanie: może używać innego konta, magazynu konfiguracji lub trasy. Celem jest udana operacja Subversion przez zamierzonego pośrednika, a nie tylko udane zwykłe żądanie strony internetowej.