متى يجب تقسيم المشروع متعدد الوحدات إلى أشجار مستودعات منفصلة؟

Question

لدينا حاليًا مشروع ذو تخطيط قياسي لمستودع التخريب:

./صُندُوق
./فروع
./tags

ومع ذلك، بينما نسير على طريق OSGi والمشروع المعياري، فقد انتهى بنا الأمر إلى:

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

لا يزال "البناء" متجانسًا تمامًا من حيث أنه يبني جميع الوحدات بالتسلسل، على الرغم من أنني بدأت أتساءل عما إذا كان ينبغي لنا إعادة بناء البناء/المستودع إلى شيء أشبه بما يلي:

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

في هذا النمط، أتخيل أن كل وحدة تبني نفسها، وتخزن ثنائيها في مستودع (مخضرم، أو آيفي، أو مسار آخر لمستودع التخريب نفسه).

هل توجد إرشادات أو "أفضل الممارسات" فيما يتعلق بتخطيطات المشروع بمجرد التحول إلى وحدات؟

Answer 1

يحتوي كتاب التخريب على قسمين حول هذا:

• تخطيط المستودع
• تخطيط منظمة المستودع الخاص بك

إدخال مدونة حول هذا الموضوع: "تخطيط مستودع التخريب"

الجواب القصير، على الرغم من:في حين أن عدد الكيلومترات الخاص بك سوف يختلف (كل حالة على حدة)، فإن الخاص بك /bundle/<project>/(trunk|tags|branches) المخطط شائع إلى حد ما ومن المرجح أن يعمل بشكل جيد بالنسبة لك.

Answer 2

هذا يعود إلى حد كبير إلى التفضيل الشخصي، ولكنني أجد البنية التالية مناسبة للمشاريع الكبيرة التي تتكون من العديد من الوحدات:

branches
  project-name
    module1
      branch-name
    module2   
      possibly-another-branch-name
    branch-name-on-a-higher-level-including-both-modules
      module1
      module2
tags
  ... (same as branches)
trunk
  project-name
    module1
    module2

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

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

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

Answer 3

جمعية البناء الخيرية...

أريد فقط التأكيد على التعليق في وثائق SVN (تم اقتباسه بالفعل في إجابة أخرى، نفس الموضوع) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

يشير المقتطف إلى البنية التالية:/ trunk/ calc/ calendar/ جدول البيانات/ ... العلامات/ calc/ calendar/ جدول البيانات/ ...

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

بالنسبة لي، أميل إلى الموافقة بشدة على هذا وأفضل التصميم التالي:/ utils/ calc/ trunk/ tags/ franses/ calendar/ trunk/ tags/ franses/… Office/ Turk/ trunk/ tags/ franses/

السبب ببساطة هو أنه من غير العملي وضع علامة على مجموعة مشروع كاملة عندما يرغب المرء في وضع علامة على مجموعة فرعية محددة فقط.

دعونا نستخدم مثالا:إذا كان المشروع 1 يعتمد على ModuleA v1.1 وmoduleB v2.3، فلا أريد ظهور ModuleA v2.x الأحدث في العلامات.في الواقع، عند العودة بعد بضعة أيام/أسابيع/أشهر إلى هذا الإصدار الموسوم، سأضطر إلى فتح واصف الحزمة في الإصدار الموسوم من المشروع-1 لقراءة إصدار الوحدة النمطية A المطلوبة بالفعل.

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

لقد كان مجرد سنتي.

Answer 4

لقد أجبت على سؤال مماثل في StackOverflow سؤال حول بنية التحكم في الإصدار.إنه في الواقع يناسب بشكل أفضل هنا نظرًا لأننا نقوم بتطوير OSGi بشكل كبير ولدينا الكثير من الحزم.يجب أن أردد تعليقات أندرس ساندفيج:احتفظ بالجذع/العلامات/الفروع على مستوى الجذر نظرًا لأنك ستقوم فقط بفرع مجموعة محدودة من الوحدات.كما أنه لا يتعارض مع بناء الوحدات بشكل فردي.

لن أنسخ الإجابة التي قدمتها من قبل ولكنها ذات صلة تمامًا بهذا السؤال.