A git fetch sikerül, a git svn fetch azonban nem éri el a kiszolgálót. A közös parancs-előtag ellenére az utóbbi művelet egy másik kliensstacken keresztül beszél egy Subversion-tárolóval.

Ne feltételezze, hogy egy natív Git-http.proxy bejegyzés konfigurálja ezt a Subversion-kapcsolatot. Keresse meg azt a futásidejű konfigurációt, amelyet a Subversion-könyvtárak használnak abban a környezetben, ahol a git svn fut.

A Subversion servers konfigurációja tartalmazhatja:

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

A gazdagépnév és a port külön értékek; a HTTP-proxy lista jelölteket kínál az engedélyezett nyilvános Subversion-útvonalakhoz. A proxyfiók mezői különállnak a tároló hitelesítő adataitól. A Subversion-kiszolgálócsoport beállításai gazdagépnevekre illeszkednek, nem tetszőleges tárolóútvonalakra. Tekintse őket a Subversion felületének, nem a Git proxy-URL alternatív írásmódjának.

Windowson az útvonal lehet a meglepetés

Egy natív Subversion végrehajtható fájl és egy git svn-telepítés különböző környezeteket és különböző otthoni könyvtár-értelmezéseket használhat. Nem bizonyíték arra, hogy a git svn hívás olvasta, ha szerkeszti a svn.exe által használt konfigurációt.

Jegyezze fel, mely végrehajtható fájl és melyik könyvtárkörnyezet vesz részt, majd azonosítsa a tényleges konfigurációs helyüket. Kerülje egyetlen felhasználó útvonalának belemásolását egy gép szintű szkriptbe.

Tartsa külön a fiókokat

A proxy hitelesítheti a kimenő kapcsolatot. A Subversion-tároló ezután másik fiókot kérhet. A HTTP 407 és a tároló engedélyezési hibája különböző szakaszokat ír le.

Ha a szabályzat megtagadja az URL-t vagy az útvonalat, használja a jóváhagyott végpontot és hozzáférési rendet. Ha egy böngésző megnyitja a tároló webes felületét, az csak részleges összehasonlítás: más fiókot, konfigurációs tárolót vagy útvonalat használhat. A cél a szándékolt közvetítőn keresztüli sikeres Subversion-művelet, nem csupán egy sikeres hétköznapi weboldal-kérés.

Kapcsolódó cikkek