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 عمل ہے، محض ایک کامیاب عام ویب صفحہ درخواست نہیں۔

متعلقہ مضامین