تنظيم مستودع التخريب لآلاف العناصر

Question

قبل ان ابدا:لقد أمضيت وقتًا طويلاً في العديد من المنتديات (بما في ذلك Stack Overflow - ونعم هناك الكثير من أسئلة SO حول تنظيم svn)، والبحث في Google، وقراءة المستندات (أمتلك عددًا قليلاً من كتب Subversion).ما زلت لم أجد طريقة جيدة لتنظيم قاعدة التعليمات البرمجية الخاصة بنا في Subversion.نحن نستخدم حاليًا نظام RCS كنظام للتحكم في المراجعة كل شئ تم تخزينه في دليل RCS واحد - أعرف أنه قبيح - ولهذا السبب أعمل على تحقيق شيء أفضل.لقد استخدمت أيضًا Subversion كثيرًا، لذلك أعرف إمكانياته وكيفية عمله.لقد ترددت في طرح هذا السؤال لعدة أشهر، لأنه لا يتعلق بالبرمجة تمامًا، ولكن بما أنني لم أتمكن من التوصل إلى حل، فما هو أفضل مكان لطرح سؤالي!

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

يمكن أن يتضمن "مشروع" واحد في بيئتنا البرامج A وB وC وملف التكوين AA.يمكن لمشروع آخر استخدام البرامج C وD وE وملف التكوين BB.هناك مشروع آخر يمكن أن يقوم فقط بتغيير ملف التكوين AA، أو ربما البرنامج B.لا توجد طريقة لتصنيف البرامج أو الملفات التي تنتمي إلى المجموعة.ولهذا السبب - ليس لدي أي فكرة عن كيفية تنظيم التعليمات البرمجية لدينا في التخريب.يمكنني وضع كل شيء في صندوق المشروع الرئيسي، ولكن بعد ذلك التحقق من نسخة العمل يعني التحقق من جميع العناصر التي يزيد عددها عن 4000 عنصر.

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

ربما لا يكون Subversion هو الخيار الأفضل لنا، على الرغم من أنني يجب أن أؤمن بأنه يمكن أن ينجح.لدينا بالفعل خادم Subversion لكود الويب الخاص بنا وبرامج Java الخاصة بنا، وهو يعمل بشكل رائع، نظرًا لوجود مشاريع محددة بسهولة.لا أستطيع معرفة كيفية تنظيم مكتبة الأكواد الرئيسية لدينا.

نأمل أن يكون بعض ذلك منطقيًا ...شكرا مقدما على حكمتك!

Answer 1

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

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

Answer 2

وأود في محاولة لتنظيم بنية مجلد الملفات قبل ببساطة مجرد إلقاء قبل أن تتحول إلى مستودع التخريب.

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

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

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