حالات استخدام قائمة انتظار التصحيح الزئبقية

Question

أستخدم بقع ميركوريال في الحالات التالية:-

1. عندما أحتاج إلى السحب من مستودع بعيد ولدي تغييرات غير ملتزم بها. ثم أقوم ببساطة بإنشاء تصحيح ، و qpop ، وسحب من المستودع البعيد ، ثم استيراد التصحيح مرة أخرى.
2. عندما أحتاج إلى تحميل التصحيحات إلى مراجعة لوحات. أنا ببساطة جعل التصحيح وتحميله.

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

Answer 1

ويكي الزئبق لديه قسم جيد في حالات الاستخدام:

في تلخيص:

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

Answer 2

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

مثال:

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

في هذه المرحلة ، سنستنسخ قاعدة البيانات ونلقي تغييرًا يمكننا سحبه.

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

مرة أخرى في قاعدة البيانات الأصلية ...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

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

لتصدير التصحيح hg export <rev> سوف تصدير بقع للمراجعة.

Answer 3

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

طوابير التصحيح جيدة لـ:

• تطوير الميزات التي تنوي إرسالها لمراجعة المنبع

  نظرًا لأنه يمكن تعديل بقع في قوائم الانتظار ، فإنها توفر طريقة مثالية لتطوير ميزة بطريقة تتبعها التاريخ ، مع السماح لك بدمج التعليقات بسهولة

• تجربة إضافة ميزة جديدة

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

• الحفاظ على التخصيصات الخاصة لمشروع آخر

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

قوائم انتظار التصحيح ليس جيدة ل

• فروع طويلة الأمد

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

• تطوير المجموعة

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

Answer 4

MQ هي أداة رائعة لإدارة التطوير المتزامن. الصارخ الذاتي وترويج الذات من بلدي إجابه:

3 استخدم MQ مع تصحيح واحد (أو تصحيحات متتالية متعددة) لكل مشروع.

• الايجابيات: بسيطة وسهلة.
• السلبيات: يجب أن Qrefresh قبل التبديل وإعادة البناء بعد ؛ صعبة ومحفوفة بالمخاطر إذا لم تكن المشاريع متعامدة.

4 استخدام فرع MQ واحد لكل مشروع.

• الايجابيات: مرنة للغاية وقابلة للتطوير (لعدد المشاريع المتزامنة)
• السلبيات: يجب أن Qrefresh و QComit قبل التبديل وإعادة البناء بعد ؛ يشعر بالتعقيد.