لا يستخدم git svn بالضرورة وكيل HTTP الخاص بـ Git

git fetch ينجح، لكن git svn fetch لا يستطيع الوصول إلى الخادم. وعلى الرغم من بادئة الأمر المشتركة، فإن العملية الأخيرة تتحدث إلى مستودع Subversion عبر حزمة عميل أخرى.

لا تفترض أن إدخال http.proxy الأصلي في Git يضبط اتصال Subversion ذلك. حدّد إعدادات وقت التشغيل التي تستخدمها مكتبات Subversion في البيئة التي يعمل فيها git svn.

قد تتضمن إعدادات servers في Subversion ما يلي:

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

اسم المضيف والمنفذ قيمتان منفصلتان؛ وتوفر قائمة وكلاء HTTP مرشحين للمسارات العامة المسموح بها إلى Subversion. حقول حساب الوكيل منفصلة عن بيانات اعتماد المستودع. إعدادات مجموعات خوادم Subversion تطابق أسماء المضيفين، لا مسارات المستودع العشوائية. تعامل معها بوصفها واجهة Subversion، لا تهجئة بديلة لعنوان URL الخاص بوكيل Git.

على Windows قد يكون المسار هو المفاجأة

قد يستخدم ملف Subversion التنفيذي الأصلي وتثبيت git svn بيئتين مختلفتين وتفسيرين مختلفين للمجلد الرئيسي. وتحرير الإعدادات التي يستخدمها svn.exe ليس دليلاً على أن استدعاء git svn قرأها.

سجّل أي ملف تنفيذي وأي بيئة مكتبات مشاركة، ثم حدّد موقع إعداداتها الفعلي. تجنب نسخ مسار مستخدم واحد إلى نص برمجي على مستوى الجهاز.

أبقِ الحسابات منفصلة

قد يوثّق الوكيل الاتصال الصادر. وقد يتطلب مستودع Subversion حساباً آخر بعد ذلك. ويصف HTTP 407 وخطأ تفويض المستودع مرحلتين مختلفتين.

إذا رُفض عنوان URL أو المسار بموجب السياسة، فاستخدم نقطة النهاية المصرح بها وترتيب الوصول المعتمد. فتح المتصفح لواجهة المستودع على الويب مقارنة جزئية فقط: فقد يستخدم حساباً أو مخزن إعدادات أو مساراً آخر. الهدف هو عملية Subversion ناجحة عبر الوسيط المقصود، لا مجرد طلب عادي ناجح لصفحة ويب.