إدارة الإفراج في SVN
https://stackoverflow.com/questions/569353
-
05-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
عندما أنظر إلى سجل SVN، أتمنى أن أرى علامات تخبرني عند إجراء الإصدارات. لقد رأيت هذا في أنظمة التحكم الإصدار الأخرى مثل PVCS و perforce..
هل يمكن القيام بذلك في SVN؟ لقد فعلت القليل من الأبحاث وحتى الآن يبدو أن هذا النوع من الأشياء غير مدعومة.
يحرر
لا نريد أن نرغب في نسخ مصدرنا إلى مجلد مختلف لكل إصدار. هذا يؤدي إلى كمية هائلة من الازدواجية غير الضرورية من الملفات على آلة المطورين ويعطينا فقط سجل لعدد مراجعة كل إصدار. يمكنني أن أفعل ذلك باستخدام مستند نصي!
Edit2.
هدفي هو الحصول على عرض واحد يظهر لي التسلسل الزمني لإطلاقاتي، حيث يمكنني رؤية جميع تغييرات التعليمات البرمجية التي حدثت بين كل إصدار. هذا يسهل تجميع ملاحظات الإصدار.
المحلول
ريتشارد، العلامات قريبة جدا، لكنني أتساءل عما إذا كان ما تحتاجه قد لا يكون فرع إصدار مخصص.
لهذا، اصنع فرعا من الجذع في وقت مبكر يسمى شيء مثل "الإفراج". ثم العمل على الجذع كالمعتاد، عندما تكون جاهزا للإصدار، دمج التغييرات الخاصة بك من الجذع إلى "الإصدار". هذه هي الطريقة الوحيدة التي يجب عليك تعديلها.
يمكنك بعد ذلك علامة من الإصدار إذا كنت تريد ذلك، وليس بنسبة 100٪ ضرورية.
ولكن ماذا سيعطيك هذا فرع يحتوي على مجموعة فرعية من مراجعات الجذع فيه. تعرف على تواريخ الإصدار مع:
svn log --stop-on-copy svn://server/project/branches/release
هذا سيمنحك قائمة تواريخ الإصدار (مع المراجعات). لمعرفة ما هو في كل إصدار يفعل:
svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>
لاحظ أيضا أنه من خلال العمل بهذه الطريقة، لا تقتصر على إصدار متتابع تماما من كل شيء في الجذع - يمكنك إجراء مراجعات الكرز، باستثناء المراجعات إذا كنت لا ترغب في إطلاق سراحها بعد، ولكن لا تزال بما في ذلك المراجعات اللاحقة.
نصائح أخرى
ليس على هذا النحو. تتمثل الطريقة المقبولة للقيام بإصدار النشرات في SVN في الحصول على "علامات" حيث يتم نسخ مصدر الإصدار الخاص بك لكل إصدار معين. علي سبيل المثال /tags/release-0.11 ... ليس هناك أي شيء يمنعك من العبث مع tags الدليل عن طريق الصدفة، خارج الصندوق، ولكن بعض الناس يحبون إنشاء خطافات قبل ارتكابها لمنع الالتزام العرضي بإطلاق العلامات.
هنا المادة الكريمة وصف عملية الإفراج في SVN.
هدفي هو الحصول على عرض واحد يظهر لي التسلسل الزمني لإطلاقاتي، حيث يمكنني رؤية جميع تغييرات التعليمات البرمجية التي حدثت بين كل إصدار.
هل قمت بالتحقيق في الرسم البياني لمراجعة السلحفاة SVN؟ إذا قمت بوضع علامة على كل إصدار (الذي أشره الآخرون، فلا ينطوي على نسخ الملفات، إما على الخادم أو محطة العمل)، فيمكنك رؤية جميع المراجعات في الترتيب الزمني، مع الإشارة إلى البيانات الفعلية. يمكنك فرقتها بين الإصدارات و / أو الجذع عن طريق إزالة المراجعتين الذي تهتم به واختيار فرق من قائمة السياق.
نسخ الجذع إلى مسار العلامات في مستودع SVN هو الطريق لتحقيق ذلك. إنها نسخة SVN، لذلك لا ينتهي الأمر بتكرار الملفات على خادم مستودع SVN. لديك فقط ملفات مكررة محليا إذا اخترت تسجيل الخروج مسار SVN بخلاف الجذع. يرتكب على تلك النسخ العامل، ثم عد إلى مسار SVN الذي تم فحصه منه.
هذا هو في الأساس التنفيذ التقليدي المحدد للتفرع في SVN. ألق نظرة على كتاب SVN عبر الإنترنت لمزيد من التفاصيل.
ستكون العلامة هي رسالة الالتزام المكتوبة عند إجراء علامة للإصدار (نسخة SVN إلى العلامات / العلامات). أتلست هذه هي الطريقة الأكثر شيوعا المستخدمة.
أثناء تشغيل Subversion لا يوفر إدارة الإصدار في حد ذاته، لا يتم تكليف أدوات التحكم بالإصدار عادة مع هذا النشاط. ما تبحث عنه هو أداة نشاط / مشكلات / قضية / تغيير يمكن أن تتفاعل مع التخريب.
تحقيقا لهذه الغاية نستخدم جيرا في مكان عملي وربطها مع التخريب. توفر جيرا خريطة طريق وتغيير التاريخ الذي يتضمن مشكلات في كل إصدار. تحتوي كل واحدة من هذه المشكلات على روابط إلى التغييرات في التحكم في التعليمات البرمجية المصدرية. وبالتالي يمكنك ربط التغييرات في التعليمات البرمجية المصدرية مع إصدارات تم إصدارها.
أعتقد أنه من الأفضل بشكل عام الحفاظ على هذه الأدواتين منفصلة. على الرغم من أن Perforce على وجه الخصوص يحاول ربط الاثنين معا، فإنهم يفعلون ذلك ببساطة فقط. هناك بعض الأشياء، مثل إرسال بريد إلكتروني إلى مستخدمي التغييرات في المشكلات، إضافة تعليقات إلى المشكلات، إضافة مرفقات إلى المشكلات التي يتم إجراؤها بشكل أفضل بكثير في قطعة متخصصة مثل JIRA. من ناحية أخرى، جيرا ليست جيدة جدا في الإصدار، ودمج المصدر المتفرع ... الذي يتم التعامل معه بشكل أفضل في قطعة متخصصة مثل التخريب.
للحصول على الكشف الكامل، هناك أدوات أخرى من جيرا مثل بوجزيلا، TRAC، IBM Rational Jazz، إلخ. التي يمكن أن تفعل الشيء نفسه مع التخريب الذي يفعله جيرا على الرغم من مستويات مختلفة من الوظائف.
ألق نظرة على مواضيع كتب SVN:
العلامات والفروع هي "نسخة على الكتابة"، مما يعني أنه لا توجد نسخ إضافية في المستودع. بشكل عام، لن يحتاج المطور الفردي إلى الحصول على نسخة محلية ما لم يكن بحاجة إليه لسبب (أي النمو على فرع).
إذا قمت بوضع علامة على كل إصدار، فيمكنك رؤية العلامات عن طريق تصفح المستودع. تتحدث الروابط أعلاه مباشرة عن أدوات سطر الأوامر، ولكن هناك أيضا أدوات واجهة المستخدم الرسومية مثل Tortoissvn على Windows. يمكنك الحصول على التاريخ، هل المقارنات، إلخ.
لمعرفة التغييرات التي تم إجراؤها في الإصدار، ستظهر فقط سجل الجذع من مراجعة العلامة التي تريد الرجوع إليها إلى مراجعة العلامة السابقة +1. يبدو الأمر مثل العمل الإضافي، لكنه بسيط جدا بمجرد أن تعتاد عليه.
مع أدوات البناء الخاصة بنا، نلتزم أيضا بملف مع بعض معلومات رقم الإصدار مرة أخرى إلى الجذع، والتعليق لديه رقم إصدار البناء. إذا كان الرمز الرئيسي الخاص بك في الجذع، فيمكن أن يعمل هذا أيضا كعلامة لما هو في Build (انظر بين الإصدار).
+1 لاستخدام رسالة الالتزام.
للحصول على مشروع قمت بإنشاء مستخدم SVN يسمى Build. تستخدم آلة البناء هذه تسجيل الدخول إلى SVN. كلما قامت عملية الإنشاء / العملية ببناء، قام أيضا بتحديث ملف، وكانت رسالة ارتكاب SVN هي الإصدار / المعرف الآخر للبناء.
ثم أنشأنا أيضا علامة لهذا البناء. بهذه الطريقة في الجذع يمكننا أن نرى البنيات عند / حيث يتم تخصيتها مع تغييرات أخرى.
لذلك اقتراحي (أبسط طريقة للقيام بذلك) هي إنشاء ملفات أخرى تسمى Build (أو أي شيء آخر تريده) وإلحاق ذلك أو مجرد تعديله في البرنامج النصي / العملية المبني، ثم تحقق منه / ارتكابه بالاسم من إصدار الإصدار باعتباره رسالة الالتزام. بسيط. سيظهر بعد ذلك في استفسارات تاريخك.
بالإضافة إلى ذلك، إذا كنت تعرف المراجعات التي تقارنها، فيمكنك القيام بفرق SVN وسترى الملفات التي تغيرت وكيف بين المراجعتين.
لست متأكدا من إجمالي الإعداد الخاص بك ولكن شخص ما ذكر السلاحف. هذا بالتأكيد بداية جيدة. أنا شخصيا استخدم الكسوف مع المكون الإضافي الفرعي ويسمح لي بإجراء فرق في بيئة رسومية بين المراجعات. طالما أن لديك مشروعك، يمكنك مقارنة أي مراجعة لأي مراجعة أخرى وعلى هذا النحو، لا تحتاج إلى الحصول على كل نوع من الازدواجية الملفات.
أيضا، نسين عادة ثلاثة أدلة في كل مستودع. الفروع الجذع والعلامات. كما لاحظ شخص ما، يتم استخدام العلامات خصيصا لتحديد الإصدار.
واجهت نفس المشكلة والطريقة التي حاولت إصلاحها لإصلاحها لشركتي هي الحصول على مجلد "إصدار" في الجذع، يحتوي هذا المجلد فقط على الملف القابل للتنفيذ الفعلي أو ما يجب أن يكون جزءا من النشر.
أقوم بإنشاء مجلد جديد لكل إصدار يبدأ ب "1.0.0.0" في مجلد "الإصدار" في "الإصدار" وأيضا علامة التعليمات البرمجية مع نفس اسم مجلد الإصدار IE 1.0.0.0 في الحالة.
لست متأكدا مما إذا كانت هذه هي الطريقة الصحيحة للقيام بذلك، ولكنها تحل مشكلتي لمعرفة القابل للتنفيذ الذي قمت بنشره.
إذا قمت باتباع اتفاقية SVN العادية "العلامات / الفروع / الجذع" في جذر مستودعك، فإن المطورين عادة لن يرغبوا في التحقق من المستودع بأكمله، فقط من الجذع لأسفل.
أرغب في تقديم نهج مختلف يجب أن يساعد في حل مشكلةك المذكورة: إنشاء ملاحظات الإصدار وعرض اختلافات شفويات التعليمات البرمجية بين الإصدارات.
نستخدم أداة مساعدة تسمى subwcrev التي تأتي مع السلحفاة SVN. لدينا حدث ما بعد المبنى الذي يمسك برقم مراجعة SVN ويصيبه في ملف - في حالة مواقع الويب التي نضعها هذا في ملف يسمى الإصدار .html. ثم في أي وقت، يمكنك ربط الإفراج عنك (سواء كان التصريح الحالي حاليا في ضمان الجودة، أو أي بيئة أخرى) إلى رقم المراجعة الدقيق في SVN. لا مزيد من العلامات، لا مزيد من أتساءل ما هو مدرج في الإصدار، لا مزيد من مطوري التنصت لتحديث ملف الإصدار.
من أجل تحديد ما تم تضمينه في الإصدار، يمكنك بعد ذلك سحب سجلات SVN من المراجعة X إلى المراجعة Y ونسخ التعليقات في مستند وتحرير لإجراء ملاحظات إفراز جميلة وثيقة. وينطبق الشيء نفسه على استعراض التعليمات البرمجية أو انتهاء الإطلاقات؛ ما عليك سوى استخدام أرقام المراجعة المرتبطة بالإصدار الخاص بك .html، وخصائص.cs، readme.txt، إلخ.
أود أيضا أن أقترح وجود نوع من مستودع القطع الأثرية لعقد مبنياتك. إذا قمت بالتبديل إلى رقم مراجعة SVN كرقم الإصدار الخاص بك، فيمكنك دائما العودة إلى تلك المراجعة الدقيقة في SVN مما يعني أنك لا تحتاج إلى علامات أو نسخ من مصدرك لكل إصدار يضع حوله في SVN.
لمعلوماتك،
النسخة SVN ليست نسخة صعبة، فهذا فقط ربط لن تأخذ أي مساحة أخرى غير الملفات التي تم تغييرها. وتستغرق هذه الإصدارات مساحة على أي حال. لذا فإن إنشاء نسخة لكل إصدار لن يأخذ أي مساحة.
