سؤال

سينتقل فريقي من Visual SourceSafe إلى Subversion قريبًا، أثناء تطوير/دعم مشروع قديم في Visual Basic 6.0، لذلك لدي سؤالان:

  • ما هي أفضل أداة لتكامل Subversion IDE في Visual Studio 6؟(أم أن الأمر لا يستحق العناء...)
  • هل توجد أية ممارسات أفضل لاستخدام Subversion مع Visual Basic 6.0؟(أنواع الملفات التي يجب تجاهلها، وما إلى ذلك)
هل كانت مفيدة؟

المحلول

أوافق على أن Tortoise SVN في Windows Explorer سيكون أفضل طريقة لاستخدام SVN مع VB6.

أكبر تغيير ستجده عند الترحيل إلى SVN هو فكرة "الخروج" و"تسجيل الوصول" التي تختلف تمامًا عن "التحديث" و"الالتزام"...وبالتالي، فإن أي تكامل IDE مع VB6 يكون محدودًا لأن VB6 يدعم MSSCCI، وهي آلية السحب/الدخول.لقد استخدمت TamTam SVN ذات مرة (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) مع Visual Studio 2003، لكنه توقف لأنني وجدته مقيدًا.دمج/تفرع/إلقاء اللوم، الخ.هي ميزات قوية جدًا توفرها Tortoise SVN ولم تكن موجودة في TamTam.دجلة لديها أيضا http://svnvb6.tigris.org/, ، ولكنني لم أحاول ذلك.

مرة أخرى، على الرغم من أنك قد تحصل على بيئة تطوير متكاملة (IDE) للعمل مع VB6، إلا أنني لا أوصي به نظرًا لأن أعظم قوة للانتقال إلى SVN هي كسر فلسفة المصدر الآمن لتسجيل الوصول/المغادرة.

نصائح أخرى

نظرًا لأن Subversion يستخدم دورة التحديث/التحرير/الالتزام (بدلاً من تسجيل الدخول/الخروج)، فسوف تحتاج إلى توخي الحذر بشكل خاص مع الملفات الثنائية.تتكون معظم النماذج في VB6 من ملفين:MyForm.frm وMyForm.frx.ملفات *.frx ثنائية، وبالتالي لا يمكن دمجها.

نظرًا لذلك، سأقوم بإعداد Subversion ليتطلب "تأمين" ملفات .frx.وهذا يعني أنه يمكن لشخص واحد فقط سحب الملف في المرة الواحدة.من خلال القيام بذلك، ستفرض أن مطورًا واحدًا فقط يمكنه تعديل هذه الملفات في المرة الواحدة، وسيكون من الواضح دائمًا من هو هذا الشخص حاليًا.إذا لم تفعل هذا، فأنت تعرض نفسك لبعض الصداع الكبير.

أنواع الملفات التي يجب تجاهلها:

*.vbw
ملف مساحة العمل الذي يتم إنشاؤه تلقائيًا عند إغلاق المشروع، ويحتوي على الملفات التي قمت بفتحها وما إلى ذلك.

MSSCCPRJ.SCC
ملف حالة التحكم بالمصدر الذي تم إنشاؤه بواسطة VB6 IDE (إذا اخترت حل التحكم في SVN في Windows Explorer، فيجب عليك تعطيل المكون الإضافي للتحكم بالمصدر في VB6 ولن يتم إنشاء هذا).

*.log
هذه هي الملفات التي يتم إنشاؤها إذا حدث خطأ ما في تحميل واجهة المستخدم الرسومية للنموذج.يوجد الملف في نفس مكان ملف النموذج مع اسم يساوي ملف النموذج.
مثال: MyForm.frm يولد MyForm.log.

يجب عليك بالطبع القيام بذلك فقط إذا لم يكن لديك ملفات السجل التي تحتاجها في التحكم بالمصادر...

اعتمادًا على مقدار ما تخطط للقيام به في هذه المشاريع القديمة، سأفكر في عدم التبديل.

أنصحك حقًا بالتبديل إلى SVN.أعرف بعض المشاريع التي فقدت كود المصدر بسبب تلف قاعدة بيانات VSS.

أعتقد أن هناك أدوات تقوم بإجراء الترحيل من SourceSafe إلى SVN.(نعم - أكد ذلك بحث سريع على Google.) وبهذه الطريقة لن تفقد سجل المراجعة.

سيكون تخميني هو عدم الاهتمام بالتكامل واستخدام Tortoise SVN فقط في Windows Explorer.

بالنسبة لأنواع الملفات التي يجب تجاهلها، قم باختبارها والخروج منها وإنشاءها ومعرفة ما إذا كانت هناك أي ملفات قد تغيرت (بالنسبة لبرنامج Visual Studio الحديث، أميل إلى تجاهل ملفات .suo)

بالنسبة لجانب الخادم، يعد VisualSVN Server حلاً بسيطًا للغاية، فنحن نقوم بتشغيله في برنامج افتراضي vmware، وهو يعمل باستمرار.

إذا كنت من رجال سطر الأوامر، فأنا أحب حقًا واجهة سطر الأوامر لـ svn، وأجد أنها أقل إرباكًا للوصول إلى إجراءات معينة من السلحفاة، مثل حالة المجلد.ولكن إذا كنت من محبي المستكشف، فإن السلحفاة أكثر من كافية، فهي تأتي من عالم آمن المصدر.

الأشياء الرئيسية التي يجب تجاهلها هي:

  • القطع الأثرية القابلة للتكرار (dll، pdb، exe)
  • الإعدادات الخاصة بالبيئة (أيملف الإعدادات لملف vs، ملف csproj.user، ملفات .suo)

اعتمادًا على مقدار ما تخطط للقيام به في هذه المشاريع القديمة، سأفكر في عدم التبديل.

عند البحث في التعليمات البرمجية القديمة، من المفيد حقًا الحصول على كل التاريخ وإلقاء اللوم.SVN أفضل بكثير من VSS، لكنك ستفقد السجل عند التبديل.

إذا كنت ستجري الكثير من التطوير المستمر في VB6، فقد يكون من المفيد التبديل إلى SVN، ولكن إذا كنت ستفعل هذا كثيرًا للمضي قدمًا، فهل يستحق الأمر أيضًا مراجعة المشروع؟

لدي مشكلة مماثلة، فقط المشاريع القديمة موجودة في دلفي.لو كانوا في VB6 أعتقد أنني سأفكر في "ترقيتهم" إلى VB.Net، فقط من أجل قابلية الصيانة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top