git svn bruker ikke nødvendigvis Gits HTTP-proxy

git fetch lykkes, men git svn fetch når ikke serveren. Til tross for felles kommandoprefiks snakker den siste operasjonen med et Subversion-lager gjennom en annen klientstakk.

Ikke anta at en innebygd Git-oppføring http.proxy konfigurerer den Subversion-tilkoblingen. Finn kjøretidskonfigurasjonen som Subversion-bibliotekene bruker i miljøet der git svn kjører.

Subversions servers-konfigurasjon kan inneholde:

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

Vertsnavn og port er separate verdier; listen over HTTP-proxyer gir kandidater for tillatte offentlige Subversion-ruter. Proxykontofelt er atskilt fra lagerets påloggingsinformasjon. Subversion-servergruppeinnstillinger samsvarer med vertsnavn, ikke vilkårlige lagerstier. Behandle dem som Subversions grensesnitt, ikke som en alternativ skrivemåte for Gits proxy-URL.

På Windows kan stien være overraskelsen

En innebygd Subversion-kjørbar fil og en git svn-installasjon kan bruke ulike miljøer og ulike tolkninger av hjemmekatalogen. Det er ikke bevis for at git svn-kallet leste den, at du redigerer konfigurasjonen som svn.exe bruker.

Noter hvilken kjørbar fil og hvilket bibliotekmiljø som er involvert, og identifiser deretter deres effektive konfigurasjonsplassering. Unngå å kopiere én brukers sti inn i et skript for hele maskinen.

Hold kontoene atskilt

Proxyen kan autentisere den utgående forbindelsen. Subversion-lageret kan deretter kreve en annen konto. En HTTP 407 og en autorisasjonsfeil for lageret beskriver ulike faser.

Hvis URL-en eller ruten avvises av policyen, bruk det godkjente endepunktet og den godkjente tilgangsordningen. At en nettleser åpner lagerets webgrensesnitt, er bare en delvis sammenligning: den kan bruke en annen konto, konfigurasjonslager eller rute. Målet er en vellykket Subversion-operasjon gjennom den tiltenkte mellommannen, ikke bare en vellykket vanlig nettsideforespørsel.