التخريب - أين يجب أن تأتي SVN: الخارج؟

Question

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

Answer 1

قلقك هو أن مشروع مع "SVN: EXTRESS" يمكن أن يتغير دون أي ارتكاب لهذا المشروع. هذه مشكلة لأنه من الصعب اكتشاف تغيير كسر أو العودة إلى إصدار جيد.

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

جهة خارجية / جلود -R148 http://svn.example.com/skinproj.

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

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

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

Answer 2

أعتقد أنه يأتي إلى كيفية نضج ممارسات تطوير البرامج الخاصة بك. هل لديك عمليات إدارة التغيير؟ بناء الآلي وإعداد التقارير؟ إلخ. الشيء الأكثر أمانا للقيام به هو الارتباط بمشروع الموسومة للمشروع (أي Lib's، DLL، JAR، إلخ).

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

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

Answer 3

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

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

Answer 4

يعتمد ذلك على مدى مستقر تفكر في الجذع.

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

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

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

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

الإشارة إلى الجذع يمكن أن يؤدي أيضا إلى "مكتبة غير قابلة لمس" مشكلة.

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

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

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