الاستخدام السليم للعلامات في SCM

Question

زملائي في العمل وأوجهوا بحجة حول قيمة واستخدام العلامات في أنظمة الإصدار / SCM. نحن نتطلع إلى مجتمع Stackoverflow لوضع أفكارهم لمساعدتنا في حل المشكلة.

يدعي جانب واحد أن العلامات هي إضافة قيمة لإدارة الإصدار. مثال على استخدامها: نحن نقوم بإصدار مافن، مما يجعل علامة جديدة (اتصل به 1.0) وهي لقطة رمز تستخدم لهذا الإصدار. يجب أن تكون هذه العلامة فرعا للقراءة. عندما يحتاج الخطأ إلى إصلاحه، يمكننا تقديم نسخة من العلامة إلى فرع جديد (اتصل به 1.1). إصلاحات الأخطاء تذهب إلى هناك. قد يتم دمج هذه الإصلاحات في الجذع حتى يحصل فرع Dev الرئيسي على إصلاحات الأخطاء. أخيرا، يتم إصدار 1.1 ويتم إنشاء علامة 1.1 تلقائيا. تستمر هذه الدورة. الفائدة الرئيسية هنا من العلامة هي أنه إذا كنت بحاجة إلى إعادة إصدار الإصدار 1.0 لأي سبب من الأسباب، يمكنك فقط إصدار العلامة 1.0 بثقة لم يتم تغييرها من قبل أي شخص. أيضا، قائلا "TREEX TAG 1.0" أنظف من قول "مراجعة الإصدار 1 من الفرع 1.0 وهو الأصلي 1.0 دون الإصلاحات".

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

من الواضح أن كلتا الطريقتين تعمل. أود أن أسمع أفكار المجتمع التي يفضلها الطريقة ولماذا.

تحرير: أنا قلق قليلا من أن الطريقة "الأفضل" تعتمد على نظام SCM الأساسي. إما الاستقرار على التخريب للحصول على إجابات أو إن أمكن الاحتفاظ به SCM Agnostic.

Answer 1

من وجهة نظر SCM Agnostic، بطاقة شعار يختلف كثيرا عن المراجعة.

قد يتم تنفيذ كلاهما بنفس الطريقة، كلاهما يمثل "خطا زمنيا"، لكن هدفهم مختلف:

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

المشكلة مع SVN هي أن المراجعة والعلامة والفروع تنفذ نفسها.
ولكن ما زلت أفضل الخيار حيث يتم استخدام علامة ك فرع "للقراءة فقط".

Answer 2

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

بالتأكيد، هناك فرصة يمكنك المسمار بها، ولكن يمكن التراجع دائما. ليس هناك بالفعل سبب لعدم وجود العديد من الأسباب التي تجعلها مفيدة في المستقبل. لي أنه لا التفكير.

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

Answer 3

نعم، تريد استخدام العلامات.

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

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

المشكلة مع SVN هي أنه يطمس التمييز بين العلامات والفروع. يمكن لأي شخص أن يلتزم دائما بالعلامة، لذلك ليس مضمونا أن تكون ثابتة / ثابتة. في VCS أخرى مثل PVCS، "العلامة" غير قابلة للتغيير. يمكنك اعتماد اتفاقية فريق لمنع ارتكاب العلامات، أو حتى ربما استخدم خطافات ارتكابها لمنع ارتكاب ارتكاب علامات.

Answer 4

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

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

ثم يتم استخدام الأساس كنقطة انطلاق لجميع المهام خلال التكرار التالي: كل مهمة جديدة هي فرع جديد يبدأ من خط الأساس، والذي يعرف أن يكون مستقرا، لذلك يجب أن يكون من السهل تتبع مهما كان مكسورا في المهمة داخل المهمة نفسها وبعد

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

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

Answer 5

أحب أن أفكر في العلامات بأنها "مجرد اسم يتوهم لمراجعة". لقد فكرت في ذلك بهذه الطريقة، و iirc في mercurial فهي مجرد ذلك. في التخريب، كما تقول، فهي بالفعل (رخيصة) نسخ من الجذع / * إلى العلامات / الاسم الهائم /

بصراحة، أود أن أجمع بين الاستراتيجيتين لتحقيق أفضل النتائج: العلامة والفرع عند الإصدار. يسمى علامةك 1.0.0، فرع 1.0 الصيانة. Bugfixes تذهب إلى الفروع، وكلامات Bugfix هي العلامات مرة أخرى (1.0.1 قد تكون علامة تهدف إلى الاسم المستعار 1.0 الصيانة في نقطة معينة.)

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

المشكلة التي أراها على الرغم من النهج الثاني هي: كيف ستجري تمييزا سهلا بين البرامج في هذا المجال إذا قمت بإعادة إصدار 1.0؟ هذا يعني أنه قد يكون لديك 1.0 و 1.0 آخر يشير في الواقع إلى قاعدة شفرة مختلفة ....

Answer 6

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

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

Answer 7

في SVN، الفرق التقني بين استخدام العلامة وتتبع المراجعة هو NIL. أجد نفسي تقليل استخدام العلامات بناء على كيفية تطبيق SVN هو ببساطة نسخة رخيصة والجلد حتى "مساحة الهيكل".

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

Answer 8

كنت الجمع بين كلا النهجين. كلما قمت بالإفراج، ضع علامة عليه. يجب ألا تتغير العلامات، وبالتالي فإن وجود علامة "1.0.0" مؤشر لا يجب أن تحاول إطلاق أي شيء آخر ك 1.0.0.

في الوقت نفسه، عندما حان الوقت للقيام 1.0.0، سأضعه على فرع 1.0. لذلك التدفق هو: Tranch Trunk إلى 1.0، علامة هذا الجديد 1.0 ك 1.0.0، ونشر. ثم يمكن إجراء إصلاحات الأخطاء في الفرع 1.0 (لتجنب التعامل مع أي تطور مستهدف 1.1 قد يكون بالفعل في الجذع الآن) واندمجت في الجذع. يتم تمييز كل إصدار من الثابت 1.0 على أنه 1.0.x من فرع 1.0. هذا هو الأساس النهج الذي نستخدمه في العمل مع Perforce، وهذا مشابه للغاية بالفعل للتخريب. (القراءة من خلال الردود، أعتقد أنها متطابقة تقريبا توصية فنسنت)

فيما يتعلق بالتعليق حول العلامات زائدة عن الحاجة لأنك تعاني من أرقام مراجعة --- هذا صحيح إلى حد كبير، إلا أن العلامات تحدد أيضا نطاقا: أي الملفات التي يتم تغطيتها بالملفات في المستودع. يمكنك أن تسأل بشكل معقول أن ينظر شخص ما إلى /svn/proj1/tag/1.0.0 وينظرون على الفور إلى مساحة عمل متماسكة. إذا طلبت منهم أن ننظر إلى المراجعة X، فلا عليهم أولا أن ننظر إلى المراجعة X لمعرفة أنه كان يتغير (قل) / SVN / PROJ1 / TRUNK / MICFILE، وبالتالي استنتاج ذلك / SVN / PROJ1 / Trunk / @ x يجب أن يبحثوا في. ماذا يحدث إذا قام المراجعة X بتمس الملفات في Proj1 و Proj2؟ وهو شر بالطبع، ولكن يتحدث بدقة يجب أن تقول / svn / proj1 / trunk / @ @ x. وأين هي قائمة أرقام المراجعة المخزنة؟ كيف نعرف أن 1.0.0 مراجعة س؟ يجب أن يكون IMHO ممكن لتحديد ذلك فقط من المستودع.

في أنظمة مثل git، لا تزال العلامات والفروع في الأساس نفس الشيء (مجرد مراجع إلى قاعدة بيانات الكائن)، ولكن مؤتمر . PERFORCE لديها أيضا "الملصقات" التي هي طرق لتجميع مجموعة من تنقيحات الملفات معا بشكل مستقل عن أي تغيير عن التغيير؛ وهو في الأساس علامة، ولكن أكثر مربكة: تاريخيا لقد استخدمنا أرقام التغييرات (ما يعادل أرقام مراجعة التخريب) المؤهلة باسم الفرع الذي يجب أن يكون عليه تحديد الإصدارات. الاثنان متطابقة تقريبا بأي حال من الأحوال، لذلك أعتقد أن TMTOWTDI.