هيكلية مستودعات SVN

السلام عليكم

منذ فترة ناقشنا موضوع أرشفة التغييرات versioning في الجامعة
واستقررنا على استخدام SVN كأداة لهذه العملية
لي فترة أعمل على إدارته وتقسيم ملفاته
كتبت مقالة عنه مسبقاً بعنوان كلام في CVS
وحيث أني المسؤول عن إدارة SVN فتوجب علي أن اقترح هيكلية مناسبة
استقررت على أربع هيكليات ممكن استخدامها ولكل من منها مزاياه وعيوبه
1- مستودع واحد لكل البرامج في المؤسسة
2- مستودع لكل برنامج في المؤسسة (يتضمن بداخله كل ما يتعلق في البرنامج)
3- كذا مستودع لكل برنامج في المؤسسة (مستودع للشيفرة الجافا مستودع للتحليل مستودع PLSQL … إلخ)
4- مستودع لكل قسم (مستودع وحيد لشيفرة الجافا يحتوي على مجلدات كل مجلد خاص بشيفرة الجافا لمشروع معين)

1- مستودع واحد لكل البرامج في المؤسسة
أسهل في عمليات الإدارة administration
يحتوي على إصدارة موحدة لكل البرامج
بمعنى آخر لا تعني الإصدارة أي شيء لأي أحد
بمعنى ثالث الإصدارة غير منطقية لأحد

2- مستودع لكل برنامج في المؤسسة
أصعب في عمليات الإدارة
الإصدارة ذات معنى لكل البرنامج
يمكن أخذ البرنامج كاملاً بتاريخه وبيعه لمؤسسة أخرى -بالطبع هذه ميزة ترفع سعر البرنامج أضعاف مضاعفة خصوصاً بين الشركات البرمجية-
يشترك أكثر من جهة -التحليل، برمجة PLSQL، برمجة جافا,… إلخ- في نفس الإصدارة وهذا عيب لكن في النهاية يبقى الموضوع منطقياً لأن الجهات مرتبطة بنفس البرنامج

3- كذا مستودع لكل برنامج في المؤسسة
أصعب بكثير في عمليات الإدارة
الإصدارة ذات معنى على مستوى الفريق -فريق التحليل فريق البرمجة وهكذا-
فيمكنك أن تبيع التحليل لوحده
وكود الجافا لوحده … إلخ

4- مستودع لكل قسم
سهل في الإدارة
هذا الخيار مفضل على الخيار الأول لأنه يقلل حتى إدارة الصلاحيات في المؤسسات التي يعمل فيها شخص ما -أو مجموعة من الأشخاص- على وظيفة ما باستمرار
الإصدارة لا تعني شيء على مستوى البرنامج بينما تعني على مستوى الفريق

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

ملاحظة: SVN لا يعاني من أي مشاكل بسبب زيادة حجم المستودعات لذا لا تحسب هذه النقطة في الهيكلية الأولى والرابعة ولو حسبت لقضي أمرهم تماماً :)
بالمناسبة نحن قررنا استخدام الهيكلية الثانية لدينا في الجامعة

أخيراً أية إضافا على الموضوع سأكون ممتن لكم :)

تحياتي

7 Responses to “هيكلية مستودعات SVN”

  1. نستخدم أيضا الطريقه الثانيه في العمل … لكن لا نقوم بعمل نسخ لل PLSQL على ال SVN … فال DBA ينسخها بطريقته (إن وجدت و التى لا أعرفها)

  2. أيضا … لو كنت أنا المسؤل عن ال SCM … ما كنت لأستخدم SVN … ربما كنت أستخدم GIT لسببين … الأول نوع من مواكبة التطوير و الثانى لأجرب العمل على DVCS (http://en.wikipedia.org/wiki/Distributed_revision_control).. و إن كنت أري أن SVN و أخواتها من نوع Client-Server مناسبة أكثر لمثل مشاريعنا التى يكون العمل عليها من داخل نفس النطاق الجغرافى

  3. admin قال:

    يجب أن نعرف تلك الطريقة علي أوجه الـ DBA عندنا إليها

    تحياتي

  4. admin قال:

    كذا واحد مدح git على حساب svn لكن بعد فوات الأوان
    كنت قد عملت دورات عليها وقد بدأنا في العمل عليها
    لا يمكنني تضييع وقت جديد في العمل منذ البداية خصوصاً ولدي درزينة مهام وهذه واحدة منها

    تحياتي

  5. في الشركة القديمه كان ال DBA يقوم بعمل ملف برقم النسخه لكل تعديل في ال PL … مثلا insert_empl_1.sql و من ثم أي تعديل يطرأ يقوم بعمل ملف جديد له و يسميه insert_empl_2.sql …
    و هذا الملفات جميعها يتم تخزينها على ال SVN في النهايه …. فلكل PL تجد مجموعه من الملفات تسجل النسخ المختلفه لهذا ال PL

  6. admin قال:

    مممممممممممممممممم
    يقوم فعلياً بما يقوم به SVN فلماذا لا يستخدمه؟

Leave a Reply