كيفية إدارة التنمية المتزامنة مع الزئبق؟

Question

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

بادئ ذي بدء ، أنا أتحدث عن تغييرات مختلفة لنفس المشروع ، لذلك لا يوجد Subrepo من فضلك.

دعنا نقول أن لديك قاعدة التعليمات البرمجية في مستودع الزئبق. تبدأ في العمل على ميزة جديدة معقدة A ، ثم يتم الإبلاغ عن خطأ معقد B بواسطة اختبار موثوق به (لديك اختبار ، أليس كذلك؟).

إنه تافهة إذا كان (الإصلاح) B يعتمد على A.

سؤالي هو ما يجب فعله عندما يكونون مستقلين (أو على الأقل يبدو الآن).

يمكنني التفكير في الطرق التالية:

1. استخدام استنساخ منفصل ل B.
2. استخدم فروع مجهولة أو تسميها ، أو الإشارات المرجعية ، في نفس المستودع.
3. استخدم MQ (مع تصحيح B أعلى A).
4. استخدم MQ المتفرعة (سأشرح لاحقًا).
5. استخدم MQ متعددة (منذ 1.6)

1 و 2 مغطاة بواسطة مدونة ممتازة بواسطة Steve Losh مرتبط من أ سؤال مرتبط قليلا.

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

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

4 يمكن أن تجعلك بالدوار لكنها الطريقة الأقوى والمرونة والقابلة للتطوير. أنا افتراضي hg qinit مع -c نظرًا لأنني أرغب في وضع علامة على بقع العمل في Progress ودفعها/سحبها ، لكن الأمر يتطلب قفزة مفاهيمية لإدراك أنه يمكنك التفرع في MQ Repo أيضًا. فيما يلي الخطوات (mq = hg -mq):

1. hg qnew bugA; ؛ إجراء تغييرات ل hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; ؛ إجراء تغييرات ل B ؛ hg qref
5. mq branch branchB; hg qci
6. للعمل مرة أخرى: hg qpop; mq up branchA; hg qpush

يبدو من الجنون اتخاذ العديد من الخطوات ، وكلما احتجت إلى تبديل العمل ، يجب عليك hg qci; hg qpop; mq up <branch>; hg qpush. ولكن ضع في اعتبارك هذا: لديك العديد من فروع الإصدار المسماة في نفس المستودع ، وتحتاج إلى العمل في العديد من المشاريع وإصلاحات الأخطاء في نفس الوقت لجميعها (من الأفضل أن تحصل على مكافأة مضمونة لهذا النوع من العمل). ستضيع قريبًا مع الأساليب الأخرى.

الآن زملائي عشاق HG ، هل هناك بدائل أخرى/أفضل؟

---

(تحديث) qqueue تقريبا يجعل #4 عفا عليها الزمن. انظر وصف ستيف لوش الأنيق هنا.

Answer 1

يبدو أنه لا توجد خيارات أكثر أو أفضل من تلك التي أدرجتها في السؤال. حتى هنا هم مرة أخرى.

1. استخدام استنساخ واحد لكل مشروع.
   • الايجابيات: الفصل الكلي ، وبالتالي لا إعادة البناء عند تبديل المشاريع.
   • السلبيات: يحتاج أدوات إلى التبديل بين استنساخين.
2. استخدم فروع مجهولة أو تسميها ، أو الإشارات المرجعية ، في نفس المستودع.
   • الايجابيات: ممارسة HG (أو أي DVCs) ؛ نظيف و واضح.
   • السلبيات: يجب أن تلتزم قبل التبديل وإعادة البناء بعد.
3. استخدم MQ مع تصحيح واحد (أو تصحيحات متتالية متعددة) لكل مشروع.
   • الايجابيات: بسيطة وسهلة.
   • السلبيات: يجب qrefresh قبل التبديل وإعادة البناء بعد ؛ صعبة ومحفوفة بالمخاطر إذا لم تكن المشاريع متعامدة.
4. استخدم فرع MQ واحد (أو qqueue في 1.6+) لكل مشروع.
   • الايجابيات: مرنة للغاية وقابلة للتطوير (لعدد المشاريع المتزامنة)
   • السلبيات: يجب qrefresh و qcommit قبل التبديل وإعادة البناء بعد ؛ يشعر بالتعقيد.

كما هو الحال دائمًا ، لا توجد رصاصة فضية ، لذا اختر واختر الحق في الوظيفة.

---

(تحديث) لأي شخص يحب MQ ، باستخدام MQ على رأس الفروع العادية ( #2 + #3) هو الممارسة الأكثر شيوعًا والمفضل.

إذا كان لديك مشروعان متزامنان مع خط أساسي على فرعين (على سبيل المثال الإصدار التالي والإصدار الحالي) ، فمن التافهة القفز بينهما مثل هذا:

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}

للخطوة الأخيرة ، qimport يجب إضافة أ -a خيار لاستيراد خط من التغييرات في وقت واحد. آمل مايستر جيسلر يلاحظ هذا :)

Answer 2

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

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

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

Answer 3

لذا فإن السؤال هو ، في النقطة التي يُطلب منك فيها التوقف عن العمل على الميزة A ، وابدأ ميزة مستقلة B ، ما هي الخيارات البديلة الموجودة ، ل: كيفية إدارة التطوير المتزامن مع الزئبق؟

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

كنت أستخدم دائمًا فروعًا مسماة ، لأن ذلك يتيح لـ Mercurial القيام بعمله: للحفاظ على تاريخ مشروعك ، وتذكر سبب قيامك بتغيير ما هو ترتيب رمز المصدر الخاص بك.

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

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

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

فقط الخيار 1 الخاص بك هو المنطقي بالنسبة لي. على العموم:

1. يجب أن تفكر في أن الكود الخاص بك يعمل ، قبل أن يراها شخص آخر.
2. تفضل الرأس على فرع.
3. الفرع وتسجيل الوصول إذا كان شخص آخر يلتقط المشكلة.
4. فرع إذا كان نظامك الآلي أو المختبرين بحاجة إلى الكود الخاص بك فقط.
5. فرع إذا كنت جزءًا من فريق ، تعمل على مشكلة. فكر في الرأس ، انظر 1-4.

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