git svn bruger ikke nødvendigvis Gits HTTP-proxy

git fetch lykkes, men git svn fetch kan ikke nå serveren. Trods det fælles kommandopræfiks taler den sidste handling med et Subversion-lager gennem en anden klientstak.

Antag ikke, at en indbygget Git-post http.proxy konfigurerer den Subversion-forbindelse. Find den runtime-konfiguration, som Subversion-bibliotekerne bruger i det miljø, hvor git svn kører.

Subversions servers-konfiguration kan indeholde:

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

Værtsnavn og port er separate værdier; listen over HTTP-proxyer leverer kandidater til tilladte offentlige Subversion-ruter. Proxykontofelter er adskilt fra lagerets legitimationsoplysninger. Subversions servergruppindstillinger matcher værtsnavne, ikke vilkårlige lagerstier. Behandl dem som Subversions grænseflade, ikke som en alternativ stavemåde for Gits proxy-URL.

På Windows kan stien være overraskelsen

En indbygget Subversion-kørbar fil og en git svn-installation kan bruge forskellige miljøer og forskellige fortolkninger af hjemmemappen. Det er ikke bevis for, at git svn-kaldet læste den, at redigere den konfiguration, som svn.exe bruger.

Notér, hvilken kørbar fil og hvilket biblioteksmiljø der er involveret, og identificér derefter deres effektive konfigurationsplacering. Undgå at kopiere én brugers sti ind i et script for hele maskinen.

Hold konti adskilt

Proxyen kan autentificere den udgående forbindelse. Subversion-lageret kan derefter kræve en anden konto. En HTTP 407 og en lagerautorisationsfejl beskriver forskellige faser.

Hvis URL'en eller ruten afvises af politikken, brug det godkendte endepunkt og den godkendte adgangsordning. At en browser åbner lagerets webgrænseflade er kun en delvis sammenligning: den kan bruge en anden konto, konfigurationslager eller rute. Målet er en vellykket Subversion-handling gennem det tilsigtede mellemled, ikke blot en vellykket almindelig websideanmodning.