git svn ले अनिवार्य रूपमा Git को HTTP प्रोक्सी प्रयोग गर्दैन
git svn अर्को क्लाइन्ट स्ट्याकमार्फत Subversion सँग कुरा गर्छ। त्यो वातावरणले पढ्ने Subversion कन्फिगरेसन पत्ता लगाउनुहोस्।
git fetch सफल हुन्छ, तर git svn fetch सर्भरमा पुग्न सक्दैन। आदेशको उपसर्ग साझा भए पनि, पछिल्लो अपरेसन अर्को क्लाइन्ट स्ट्याकमार्फत Subversion भण्डारसँग कुरा गर्छ।
Git को मूल http.proxy प्रविष्टिले त्यो Subversion जडान कन्फिगर गर्छ भनी नमान्नुहोस्। git svn चल्ने वातावरणमा Subversion पुस्तकालयहरूले प्रयोग गर्ने रनटाइम कन्फिगरेसन पत्ता लगाउनुहोस्।
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 अपरेसन हो, केवल सफल सामान्य वेब पृष्ठ अनुरोध होइन।