git svn använder inte nödvändigtvis Gits HTTP-proxy

git fetch lyckas, men git svn fetch når inte servern. Trots det gemensamma kommandoprefixet talar den senare operationen med ett Subversion-arkiv via en annan klientstack.

Anta inte att en inbyggd Git-post http.proxy konfigurerar den Subversion-anslutningen. Hitta den runtime-konfiguration som Subversion-biblioteken använder i miljön där git svn körs.

Subversions servers-konfiguration kan innehålla:

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

Värdnamnet och porten är separata värden; listan över HTTP-proxyer ger kandidater för tillåtna offentliga Subversion-rutter. Proxykontofält är åtskilda från arkivets inloggningsuppgifter. Subversions servergruppsinställningar matchar värdnamn, inte godtyckliga arkivsökvägar. Behandla dem som Subversions gränssnitt, inte som en alternativ stavning av Gits proxy-URL.

I Windows kan sökvägen vara överraskningen

En inbyggd Subversion-körbar fil och en git svn-installation kan använda olika miljöer och olika tolkningar av hemkatalogen. Det är inte bevis för att git svn-anropet läste den, att du redigerar konfigurationen som svn.exe använder.

Notera vilken körbar fil och vilken biblioteksmiljö som är inblandad och identifiera sedan deras effektiva konfigurationsplats. Undvik att kopiera en användares sökväg till ett skript för hela maskinen.

Håll kontona åtskilda

Proxyn kan autentisera den utgående anslutningen. Subversion-arkivet kan därefter kräva ett annat konto. En HTTP 407 och ett auktoriseringsfel för arkivet beskriver olika faser.

Om URL:en eller rutten nekas av policyn, använd den godkända slutpunkten och åtkomstordningen. Att en webbläsare öppnar arkivets webbgränssnitt är bara en delvis jämförelse: den kan använda ett annat konto, en annan konfigurationslagring eller en annan rutt. Målet är en lyckad Subversion-åtgärd via den avsedda mellanhanden, inte bara en lyckad vanlig webbsideförfrågan.