git fetch წარმატებით სრულდება, მაგრამ git svn fetch სერვერს ვერ აღწევს. მიუხედავად ბრძანების საერთო პრეფიქსისა, მეორე ოპერაცია Subversion-ის საცავს სხვა კლიენტური სტეკით ესაუბრება.

ნუ ჩათვლით, რომ Git-ის მშობლიური http.proxy ჩანაწერი ამ Subversion-ის კავშირს აყენებს. იპოვეთ ის გაშვების დროის კონფიგურაცია, რომელსაც Subversion-ის ბიბლიოთეკები იყენებენ გარემოში, სადაც git svn მუშაობს.

Subversion-ის servers კონფიგურაცია შეიძლება შეიცავდეს:

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

ჰოსტის სახელი და პორტი ცალკე მნიშვნელობებია; HTTP პროქსების სია კანდიდატებს გვთავაზობს დაშვებული საჯარო Subversion მარშრუტებისთვის. პროქსის ანგარიშის ველები განცალკევებულია საცავის სერტიფიკატებისგან. Subversion-ის სერვერული ჯგუფების პარამეტრები ჰოსტის სახელებს ემთხვევა, არა თვითნებურ საცავის გზებს. განიხილეთ ისინი როგორც Subversion-ის ინტერფეისი, და არა როგორც Git-ის პროქსის URL-ის ალტერნატიული ჩაწერა.

Windows-ზე გზა შეიძლება სიურპრიზი იყოს

Subversion-ის მშობლიური შესრულებადი ფაილი და git svn-ის ინსტალაცია შეიძლება სხვადასხვა გარემოსა და სახლის კატალოგის სხვადასხვა ინტერპრეტაციას იყენებდეს. svn.exe-ის მიერ გამოყენებული კონფიგურაციის რედაქტირება არ არის მტკიცებულება, რომ git svn-ის გამოძახებამ ის წაიკითხა.

ჩაიწერეთ, რომელი შესრულებადი ფაილი და რომელი ბიბლიოთეკური გარემო მონაწილეობს, შემდეგ განსაზღვრეთ მათი ფაქტობრივი კონფიგურაციის ადგილი. მოერიდეთ ერთი მომხმარებლის გზის მთელი მანქანის სკრიპტში კოპირებას.

ანგარიშები ცალ-ცალკე შეინახეთ

პროქსიმ შეიძლება გარე კავშირი ავთენტიფიციროს. Subversion-ის საცავმა შეიძლება შემდეგ სხვა ანგარიში მოითხოვოს. HTTP 407 და საცავის ავტორიზაციის შეცდომა სხვადასხვა ეტაპს აღწერს.

თუ URL ან მარშრუტი პოლიტიკით აკრძალულია, გამოიყენეთ დამტკიცებული საბოლოო წერტილი და წვდომის წესი. ბრაუზერში საცავის ვებ-ინტერფეისის გახსნა მხოლოდ ნაწილობრივი შედარებაა: შეიძლება სხვა ანგარიში, კონფიგურაციის საცავი ან მარშრუტი გამოიყენოს. მიზანია წარმატებული Subversion ოპერაცია განზრახული შუამავლის მეშვეობით, და არა უბრალოდ წარმატებული ჩვეულებრივი ვებ-გვერდის მოთხოვნა.

დაკავშირებული სტატიები