git svn ज़रूरी नहीं कि Git का HTTP प्रॉक्सी इस्तेमाल करे

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 ऑपरेशन है, केवल एक सफल सामान्य वेब पेज अनुरोध नहीं।