باستخدام التخريب مع النموذج الترويجي

Question

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

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

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

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

تحرير - إضافة المزيد من المعلومات.

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

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

في هذه الحالة ، نريد ميزة 2 (مكتمل في الفرع أ) في الفرع B ، ولكن نظرًا لأن هذا دمج من الأطفال إلى الوالدين ، وبالتالي لا يدعمه التخريب ، فسيتعين القيام به يدويًا. وبالمثل ، يجب دمج الميزة 6 يدويًا مرتين. أتوقع أن تكون هذه عملية بطيئة نسبيًا ومعرضة للخطأ مقارنةً بدمج تعقب تلقائيًا.

Answer 1

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

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

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

SVN لا "تتبع دمج" أكثر مما يدعم الفروع (وهو ما لا ، فهي مجرد نسخ خفيفة الوزن). أنت تخبره (أو يخبرها Svnmerge) النطاقات لدمج وتطبق تلك التغييرات. يمكنك الحصول على تأثير مطلوب تعاقدي لدعمه ، بغض النظر.

للإجابة على أسئلتك المقدمة:

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

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

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

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

هتافات!

Answer 2

قول انت:

كل العمل من الفروع السابقة يجب أن تجعلها في وقت لاحق. يجب ألا يدفع العمل في الفروع اللاحقة إلى الأفراق السابقة (هذا في عقودنا)

هنا ، إذا استبدلنا الفروع بالإصدارات (أشك في أن عملائك يعرفون أو يهتمون بـ "الفروع") ، نحصل على:

يجب أن تجعل جميع الأعمال من الإصدارات السابقة في وقت لاحق. يجب ألا يدخل العمل في الإصدارات اللاحقة إلى الإصدارات السابقة (هذا في عقودنا)

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