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 কাজ, কেবল একটি সফল সাধারণ ওয়েব পৃষ্ঠা অনুরোধ নয়।