git svn не абавязкова выкарыстоўвае HTTP-проксі Git

git fetch паспяхова выконваецца, але git svn fetch не можа дасягнуць сервера. Нягледзячы на агульны прэфікс каманды, апошняя аперацыя размаўляе з рэпазіторыем Subversion праз іншы кліенцкі стек.

Не мяркуйце, што ўласны запіс Git http.proxy наладжвае гэтае злучэнне з Subversion. Знайдзіце канфігурацыю часу выканання, якую выкарыстоўваюць бібліятэкі Subversion у асяроддзі, дзе працуе git svn.

Канфігурацыя servers у Subversion можа змяшчаць:

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

Імя хоста і порт — асобныя значэнні; спіс HTTP-проксі дае кандыдатаў для дазволеных публічных маршрутаў Subversion. Палі ўліковага запісу проксі аддзеленыя ад уліковых даных рэпазіторыя. Налады груп сервераў Subversion супастаўляюцца з імёнамі хостаў, а не з адвольнымі шляхамі рэпазіторыя. Разглядайце іх як інтэрфейс Subversion, а не як альтэрнатыўнае напісанне URL проксі Git.

У Windows шлях можа стаць нечаканасцю

Уласны выканальны файл Subversion і ўсталяванне git svn могуць выкарыстоўваць розныя асяроддзі і па-рознаму тлумачыць хатні каталог. Рэдагаванне канфігурацыі, якую выкарыстоўвае svn.exe, не з'яўляецца доказам таго, што выклік git svn прачытаў яе.

Запішыце, які выканальны файл і якое асяроддзе бібліятэк задзейнічаны, затым вызначце іх фактычнае месца канфігурацыі. Пазбягайце капіравання шляху аднаго карыстальніка ў сцэнар для ўсёй машыны.

Трымайце ўліковыя запісы асобна

Проксі можа аўтэнтыфікаваць знешняе злучэнне. Рэпазіторый Subversion можа пасля гэтага патрабаваць іншы ўліковы запіс. HTTP 407 і памылка аўтарызацыі рэпазіторыя апісваюць розныя этапы.

Калі URL або маршрут забаронены палітыкай, выкарыстоўвайце ўзгоднены канчатковы пункт і парадак доступу. Адкрыццё вэб-інтэрфейсу рэпазіторыя ў браўзеры — толькі частковае параўнанне: ён можа выкарыстоўваць іншы ўліковы запіс, сховішча канфігурацыі або маршрут. Мэта — паспяховая аперацыя Subversion праз прызначаны пасярэднік, а не проста паспяховы звычайны запыт вэб-старонкі.