git svn لزوماً از پروکسی HTTP گیت استفاده نمی‌کند

git fetch موفق می‌شود، اما git svn fetch نمی‌تواند به سرور برسد. با وجود پیشوند مشترک فرمان، عملیات دوم از طریق پشتهٔ کلاینت دیگری با مخزن Subversion صحبت می‌کند.

فرض نکنید که ورودی بومی http.proxy در گیت آن اتصال Subversion را پیکربندی می‌کند. پیکربندی زمان اجرایی را پیدا کنید که کتابخانه‌های Subversion در محیط اجرای git svn استفاده می‌کنند.

پیکربندی servers در Subversion می‌تواند شامل این باشد:

[global]
http-proxy-host = proxy.example
http-proxy-port = 8080

نام میزبان و پورت مقادیر جداگانه‌ای هستند؛ فهرست پروکسی HTTP نامزدهایی برای مسیرهای عمومی مجاز Subversion فراهم می‌کند. فیلدهای حساب پروکسی از اعتبارنامه‌های مخزن جدا هستند. تنظیمات گروه سرور Subversion با نام میزبان‌ها مطابقت دارند، نه با مسیرهای دلخواه مخزن. آن‌ها را به‌عنوان رابط Subversion در نظر بگیرید، نه املای جایگزین نشانی پروکسی گیت.

در ویندوز، مسیر می‌تواند غافلگیری باشد

یک فایل اجرایی بومی Subversion و یک نصب git svn می‌توانند از محیط‌های متفاوت و تفسیرهای متفاوت از پوشهٔ خانه استفاده کنند. ویرایش پیکربندی‌ای که svn.exe استفاده می‌کند مدرکی نیست بر اینکه فراخوانی git svn آن را خوانده است.

ثبت کنید که کدام فایل اجرایی و کدام محیط کتابخانه‌ای دخیل است، و سپس مکان مؤثر پیکربندی آن‌ها را مشخص کنید. از کپی کردن مسیر یک کاربر در یک اسکریپت سراسری ماشین خودداری کنید.

حساب‌ها را جدا نگه دارید

پروکسی ممکن است اتصال خروجی را احراز هویت کند. مخزن Subversion ممکن است پس از آن حساب دیگری بخواهد. HTTP 407 و خطای مجوز مخزن مراحل متفاوتی را توصیف می‌کنند.

اگر سیاست، نشانی یا مسیر را رد می‌کند، از نقطهٔ پایانی تأییدشده و ترتیب دسترسی مصوب استفاده کنید. باز کردن رابط وب مخزن در مرورگر تنها مقایسه‌ای جزئی است: ممکن است از حساب، انبار پیکربندی یا مسیری دیگر استفاده کند. هدف، یک عملیات موفق Subversion از طریق واسطهٔ مورد نظر است، نه صرفاً یک درخواست معمولی موفق صفحهٔ وب.