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 ऑपरेशन आहे, केवळ यशस्वी सामान्य वेब पृष्ठ विनंती नाही.