التعامل مع العلاقات بين مشاريع التخريب المتعددة

Question

نستخدم في شركتي مستودع SVN واحدًا للاحتفاظ برمز C++ الخاص بنا.تتكون قاعدة التعليمات البرمجية من جزء مشترك (البنية التحتية والتطبيقات)، ومشاريع العميل (التي تم تطويرها كمكونات إضافية).

يبدو تخطيط المستودع كما يلي:

• بنية تحتية
• التطبيق1
• التطبيق2
• التطبيق3
• مشروع للعميل-1
  • App1-plugin
  • App2-plugin
  • إعدادات
• مشروع للعميل-2
  • App1-plugin
  • App2-plugin
  • إعدادات

يتضمن الإصدار النموذجي لمشروع عميل بيانات المشروع وكل مشروع يستخدمه (على سبيل المثال.بنية تحتية).

التخطيط الفعلي لكل دليل هو -

• بنية تحتية
  • الفروع
  • العلامات
  • صُندُوق
• مشروع للعميل-2
  • الفروع
  • العلامات
  • صُندُوق

وهكذا الحال بالنسبة لبقية المشاريع.

لدينا العديد من المشاكل في التصميم أعلاه:

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

هل هناك أي طريقة في SVN لحل أي مما سبق؟فكرت في استخدام svn:externals في مشاريع العميل، ولكن بعد القراءة هذا المشنور أفهم أنه قد لا يكون الاختيار الصحيح.

Answer 1

يمكنك التعامل مع هذا باستخدام svn:externals.إحدى الطرق لاستخدام ذلك هي ضمن project-for-client2، حيث يمكنك إضافة رابط svn:externals إلى فرع البنية التحتية الذي تحتاجه، وفرع app1 الذي تحتاجه، وما إلى ذلك.لذا، عندما تقوم بفحص المشروع مقابل العميل 2، فإنك تحصل على جميع القطع الصحيحة.

يتم إصدار الروابط svn:externals جنبًا إلى جنب مع كل شيء آخر، لذلك عندما يتم وضع علامة على المشروع مقابل العميل 1 وتفرعه وتحديثه، سيتم دائمًا سحب الفروع الخارجية الصحيحة.

Answer 2

الاقتراح هو تغيير تخطيط الدليل من

• بنية تحتية
  • الفروع
  • العلامات
  • صُندُوق
• مشروع للعميل-1
  • الفروع
  • العلامات
  • صُندُوق
• مشروع للعميل-2
  • الفروع
  • العلامات
  • صُندُوق

ل

• الفروع
  • ميزة-1
    • بنية تحتية
    • مشروع للعميل-1
    • مشروع للعميل-2
• العلامات
• صُندُوق
  • بنية تحتية
  • مشروع للعميل-1
  • مشروع للعميل-2

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

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

وهذا قد يجعل الإصدارات أكثر تعقيدًا أيضًا، ويفصل التعليمات البرمجية لمشاريع مختلفة.

Answer 3

نعم إنه مقرف.نحن نفعل نفس الشيء، لكن لا يمكنني التفكير في تصميم أفضل.

لذا، ما لدينا هو مجموعة من البرامج النصية التي يمكنها أتمتة كل ما يتعلق بالتخريب.سيحتوي مشروع كل عميل على ملف يسمى project.list, ، والذي يحتوي على جميع مشاريع/مسارات التخريب اللازمة لبناء ذلك العميل.على سبيل المثال:

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

ثم يبدو كل برنامج نصي كما يلي:

for PROJ in $(cat project.list); do
    # execute commands here
done

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

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

Answer 4

أولاً، أنا لا أوافق على أن المظاهر الخارجية شريرة.على الرغم من أنها ليست مثالية.

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

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

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

النقاط التي يجب مراعاتها - استخدام العناصر الخارجية العودية.أنا لا أقتنع بنعم أو لا في هذا وأميل إلى اتباع نهج عملي.

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

Answer 5

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

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