ما هي منهجية التحكم في الإصدار الأكثر كفاءة:الخروج أو الدمج؟

Question

لقد استخدمت دائمًا Subversion أو CVS للتحكم في الإصدار، والتي تستخدم منهجية "الدمج".أحد أصدقائي يهذي بـ Perforce ومدى روعتها من خلال قوائم التغيير ومنهجية المغادرة.

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

يحرر: للتوضيح، أعلم أن كلا من Perforce وSVN يسمحان بالقفل والدمج، لكن SVN "يشجع" طريقة تحرير ودمج ليبرالية، بينما كما أفهمها، يشجع Perforce طريقة تسجيل الخروج والدخول.

Answer 1

بصراحة أعتقد أن ذلك يعتمد على انضباط المطورين.

أستخدم Subversion في عملي الشخصي وقد استخدمته في عدد قليل من الوظائف.ما يعجبني في Subversion هو أنني لست مضطرًا إلى مطاردة شخص ما وسؤاله عن سبب عمله على شيء ما وما إذا كان من المناسب بالنسبة لي القيام ببعض الأعمال.تأتي المشكلة عندما يقرر شخص ما البدء في العمل على شيء ما ولا يتحقق منه لفترة من الوقت؛قد يؤدي ذلك إلى صعوبة الدمج حيث يتم إجراء العديد من التغييرات بين تسجيل المغادرة وتسجيل الوصول.

أستخدم Perforce الآن ولسبب ما أحب SVN بشكل أفضل.من المؤكد أن Perforce تعطيني إشارة أفضل إلى أنه سيكون هناك تعارضات دمج، كما أنها تحتوي على أدوات مدمجة لمساعدتي في حل عمليات الدمج.إنها تواجه نفس المشكلة، حيث إذا قام شخص ما بإجراء الكثير من التغييرات على مدار فترة طويلة، فسيكون الدمج أكثر صعوبة.

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

Answer 2

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

لاحظ أن Perforce لا يفرض منهجية السحب، فهو يسمح بعمليات السحب المتزامنة (أي ما يعادل الدمج).

Answer 3

في تقييمنا الأخير، تغلبت Perforce على Subversion في دعمها للتفرع ودمج التغييرات بين الفروع.كان العمل جاريًا على Subversion لمعالجة هذا القصور، لكننا لم نعد للتحقق من ذلك.

في Perforce، عندما تقوم بتفرع ملف، فإن Perforce "يتذكر" مصدر الملف والمراجعات التي تم "دمجها" في الإصدارين.يحتوي أيضًا على بعض تحسينات التخزين في المستودع بحيث لا تتحقق النسخة الفرعية فعليًا حتى يقوم شخص ما بإجراء تغيير في الفرع، وبعد ذلك (إذا فهمت بشكل صحيح)، فإنه يستخدم الاختلافات مقابل النسخة الأساسية، تمامًا مثل المراجعات داخل فرع.

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

Answer 4

ربما كنت تقصد Source Safe بدلاً من Perforce؟يدعم Perforce الدمج، وفي الواقع كان لديه دعم دمج أفضل من SVN حتى SVN 1.5 حيث تمت إضافة عمليات الدمج المسماة (بالإضافة إلى قوائم التغيير، التي كانت لدى Perforce دائمًا وأفتقد كثيرًا الانتقال إلى متجر يستخدم SVN، لكننا لن نفعل ذلك) لقد تم اختبار الترقية حتى الإصدار 1.5 بمزيد من الوقت.)

تجدر الإشارة إلى أن كلاً من SVN وPerforce يسمحان لك بإجراء عملية دفع مقفلة، لذا يمكنك القيام بالنموذج "غير المدمج" إذا كنت تريد ذلك، ولكن بصرف النظر عن إدارة الثنائيات مع التحكم في الإصدار، لا أرى فائدة كبيرة لهذا.

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

Answer 5

إذا فهمت الأمر بشكل صحيح، فإن Perforce يجعل كافة الملفات التي لم يتم سحبها للقراءة فقط.وهذا مشابه للسلوك ضمن Microsoft TFS وVSS.التخريب من ناحية أخرى لا يحدد سمات للقراءة فقط.IMO، تعد طريقة Subversion أسهل لأنك لا تحتاج إلى إزعاج عميل التحكم بالمصادر من أجل تعديل الملفات - يمكنك المضي قدمًا والتعديل بالتخلي المتهور ثم مقارنة ما تغير على القرص بالخادم عندما تكون جاهزًا لتسجيل الوصول.

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

Answer 6

إذا فهمت الأمر بشكل صحيح، فإن Perforce يجعل كافة الملفات التي لم يتم سحبها للقراءة فقط.

وهذا هو السلوك الافتراضي فقط.إذا لزم الأمر، يمكن تعيين الملفات التي تتغير بشكل متكرر لتكون للقراءة والكتابة بدلاً من ذلك.اطلع على القائمة الكاملة لمعدلات الملفات هنا.

أيضًا، بالنسبة لبيئتي، أستخدم Eclipse مع البرنامج المساعد بالضرورة.باستخدام هذا البرنامج المساعد، يؤدي تحرير الملف إلى فتح الملف للتحرير على الفور.

Answer 7

لست متأكدًا من البحث، ولكن إليك نقطة بيانات واحدة لك:
اختار فريقي PVCS (الخروج) في الغالب بسبب الراحة.من المؤكد أن الشكوك حول الدمج ونقص الوعي بأدوات مثل Subversion ساهمت في ذلك.

Answer 8

لست متأكدًا من أنني أفهم السؤال هنا - لست على علم بأي نظام حديث للتحكم في المصدر (بخلاف Visual SourceSafe) لا يدعم الدمج بشكل كامل.

Answer 9

أنا بالتأكيد أفضل منهجية الدمج.

لقد استخدمت Visual Sourcesafe (آمل ألا يحدث ذلك مرة أخرى)، وCVS، وSubversion، وbzr.تفرض أداة Visual Sourcesafe منهجية "الخروج قبل التحرير" ويمكن أن تكون مؤلمة.لم يكن CVS وSubversion جيدًا في قبول عمليات الدمج تاريخيًا، على الرغم من أنني سمعت أن Subversion 1.5 قد حسن ذلك.

أوصي باستخدام VCS الذي تم تصميمه مع وضع الدمج المتكرر في الاعتبار منذ البداية.bzr هو الذي استخدمته للقيام بذلك، لكن أنظمة vcs الموزعة الرئيسية الأخرى (git وmercurial) تفعل ذلك أيضًا.

لكن في النهاية لا أعرف أي بحث في هذا المجال بالتحديد.بشكل عام، هناك القليل جدًا من الأبحاث حول كفاءة البرمجة، أدوات الناس كونها واحدة من الاستثناءات البارزة.

Answer 10

لا أفهم حقًا السؤال، لأكون صادقًا.لكن يمكنني أن أضمن كفاءة Perforce وقدرته على التعامل مع أكثر من شخص يقوم بتعديل الملف بشكل غير متزامن، والتعامل مع دمج التعديلات.

في Perforce، إذا قام شخص ما بالتحقق من ملف تقوم بتعديله أيضًا، فعند المزامنة التالية من الخادم (على سبيل المثال،الحصول على أحدث الملفات) يتم إبلاغك بوجود بعض التغييرات التي تحتاج إلى حل.إن اختيار موعد القيام بذلك متروك لك.عندما تقوم "بحل" ملف ما، يتم دمجه في الإصدار المحلي الخاص بك - والأدوات جيدة لهذا الغرض.

من المهم أن يكون لديك خيار عند القيام بذلك - ربما تقوم بالمزامنة حتى تتمكن من الحصول على بعض التحديثات التي لا تتعلق بشكل مباشر بمهمتك (على سبيل المثال، إصلاح الأخطاء)، ولا تريد في هذه المرحلة التعامل مع العمل إذا كان شخص آخر التغيير إلى نفس الملفات التي تعمل عليها سيؤثر عليك.لذا، استمر في إجراء الإنشاء والاختبار، ثم بعد ذلك تقوم بحل الملفات في الوقت الذي يناسبك.

الحالة الأخرى هي أنك تقوم بإرسال تعديلاتك دون الحاجة إلى المزامنة أولاً مع الملف المحدث.في هذه الحالة، يمنع Perforce الإرسال ويضع علامة على الملفات المطلوب حلها.سيقوم أي مطور عاقل في هذه المرحلة بإجراء الدمج، ثم إعادة الترجمة و/أو الاختبار قبل إرسال التغيير مرة أخرى إلى Perforce.

ما يعجبني في هذا هو أنه يحاول جاهدًا منعك من إرسال التغييرات مرة أخرى إلى الخادم المركزي والتي لم تتم معالجتها بشكل صريح، وبالتالي يقلل من فرص كسر البنية.عملية الحل سهلة ومنخفضة التكلفة للغاية، لذلك لا توجد مشكلة في الكفاءة على الإطلاق.

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

أعتقد أن الأمر يرجع على الأرجح إلى ما اعتدت عليه - لا أعتقد أن هناك مشكلة كبيرة أو قابلة للقياس تتعلق بالكفاءة.