git svn ne nepre uzas la HTTP-prokuron de Git

git fetch sukcesas, sed git svn fetch ne povas atingi la servilon. Malgraŭ la komuna komanda prefikso, la lasta operacio parolas al Subversion-deponejo per alia klienta stako.

Ne supozu, ke indiĝena Git-enskribo http.proxy agordas tiun Subversion-konekton. Trovu la rultempan agordon, kiun uzas la Subversion-bibliotekoj en la medio, kie git svn ruliĝas.

La servers-agordo de Subversion povas enhavi:

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

La gastigantnomo kaj la pordo estas apartaj valoroj; la listo de HTTP-prokuroj provizas kandidatojn por permesitaj publikaj Subversion-vojoj. Prokuraj kontaj kampoj estas apartaj de la deponejaj akreditaĵoj. Subversion-servilgrupaj agordoj kongruas kun gastigantnomoj, ne kun arbitraj deponejaj vojoj. Traktu ilin kiel la interfacon de Subversion, ne kiel alternativan literumon de la prokura URL de Git.

En Windows la vojo povas esti la surprizo

Indiĝena Subversion-plenumebla dosiero kaj git svn-instalaĵo povas uzi malsamajn mediojn kaj malsamajn interpretojn de la hejmdosierujo. Redakti la agordon, kiun uzas svn.exe, ne estas pruvo, ke la git svn-voko legis ĝin.

Notu, kiuj plenumebla dosiero kaj biblioteka medio partoprenas, poste identigu ilian efektivan agordan lokon. Evitu kopii la vojon de unu uzanto en skripton por la tuta maŝino.

Tenu la kontojn apartaj

La prokuro povas aŭtentigi la eliran konekton. La Subversion-deponejo tiam povas postuli alian konton. HTTP 407 kaj deponeja rajtiga eraro priskribas malsamajn stadiojn.

Se la URL aŭ vojo estas malpermesitaj de regularo, uzu la aprobitan finpunkton kaj aliraranĝon. Malfermi la retinterfacon de la deponejo en retumilo estas nur parte komparebla: ĝi povas uzi alian konton, agordan konservejon aŭ vojon. La celo estas sukcesa Subversion-operacio tra la intencita peranto, ne nur sukcesa ordinara retpaĝa peto.