إدارة المراجعة الموزعة

تقوم إدارة المراجعة الموزعة (بالإنجليزية: Distributed revision control واختصاراً DRCS)‏ أو إدارة الإصدار الموزعة أو نظام إدارة الإصدارات المركزية (DVCS)بالاحتفاظ بتاريخ كل مراجعات برمجية حاسوب ويسمح للعديد من المطورين بالعمل في مشروع واحد بدون أن يكونوا متصلين بالضرورة علي شبكة مشتركة.

الموزعة في مقابل المركزية

تستخدم إدارة المراجعة الموزعة (DRCS)أسلوب النظير للنظير علي العكس من أسلوب العميل-الخادم الذي تتبعه النظم المركزية.[1] فبدلا من وجود مستودع مركزي واحد يقوم فيه العملاء بالعمل المتزامن، فإن نسخة عمل كل نظير في قاعدة الأكواد هي مستودع في حد ذاته. تُجري إدارة المراجعة الموزعة المزامنة عن طريق تبادل patche (يونكس) (مجموعات التغير) من نظير إلي نظير. ينتج عن ذلك بعض الاختلافات الهامة عن النظام المركزي:

  • لا توجد نسخة مرجعية أساسية من قاعدة الأكواد بشكل افتراضي ولكن توجد نسخ عمل فقط.
  • تكون العمليات المشتركة (مثل التسجيلات، والاطلاع علي التاريخ، وعكس التغييرات) سريعة لأنه لا توجد حاجة للاتصال بخادم مركزي.[2]

بدلا من ذلك فإن الاتصال ضروري فقط عند دفع أو جذب التغييرات من وإلي النظراء الآخرين.

  • تعمل كل نسخة عمل بكفاءة باعتبارها نسخة احتياطية بعيدة لقاعدة الأكواد وتاريخها المتغير مما يعتبر حماية طبيعية ضد فقدان البيانات.[2]

هناك اختلافات أخرى كالآتي:

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

يُشير أنصار نظام إدارة الإصدارات المركزية (DVCS) إلي عدة مزايا لإدارة الإصدار الموزع أفضل من النموذج المركزي:

  • السماح للمستخدمين بالعمل بإنتاجية حتي وإن لم يرتبطوا عن طريق شبكة.
  • يجعل معظم العمليات أكثر سرعة نظرا لعدم وجود شبكة.
  • يسمح بالمشاركة في المشروعات بدون طلب الإذن من سلطات المشروع وبالتالي تعزيز ثقافة حكم بالاستحقاق[بحاجة لمصدر] بدلا من طلب الحصول علي حالة «الملتزم»
  • السماح بالعمل الخاص حتي يستطيع المستخدمين استخدام نظام إدارة المراجعة حتي مع المسودات الأولية التي لا يريدون نشرها.
  • تجنب الاعتماد علي آلة واحدة كنقطة فشل واحدة
  • السماح بالإدارة المركزية للإصدار الجديد للمشروع

يصف جول سبولسكي مؤلف تطوير البرمجيات إدارة الإصدار الموزعة بأنها قد تكون أكبر تقدم في تكنولوجيا تطوير البرمجيات علي مدي العشر سنوات الأخيرة.[3]

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

النظم

النظم المفتوحة

يتسم النظام المفتوح لإدارة المراجعة الموزعة بدعمه للفروع المستقلة واعتماده الكبير علي عمليات الدمج. وتتضمن خصائصه العامة ما يلي:

  • كل نسخة عاملة هي شعبة أو تفريع فعال
  • يُطبق النظام كل فرع كنسخة عاملة مع تنفيذ بعض الدمج عن طريق تبادل عادي للـ patch من فرع إلي فرع.
  • تشعب الكود يحدث بسهولة أكبر عند الرغبة لأن كل نسخة عاملة شعبة محتملة (وبالمثل فإن الشعب غير المرغوب فيها يكون إصلاحها أسهل لأنه بما أن النزاع يمكن حله فإن إعادة دمج الكود سهلة).
  • قد يكون من الممكن التنقل بين التغيرات المفردة واختيارها من بين النظراء.
  • يستطيع النظراء الجدد المشاركة بحرية بدون طلب الدخول إلي الخادم.

من أوائل النظم المفتوحة نظام (بت كيبر) المستخدم في تطوير نواة لينكس. عندما قرر صناع (بت كيبر) في عام 2005 قصره علي الترخيص، بحث مطورو لينكس عن استبدال مجاني. تتضمن النظم المفتوحة الشائعة للاستخدام المجاني في عام 2010 ما يلي:

للحصول علي قائمة كاملة ـ أنظر مقارنة بين برمجيات إدارة المراجعة

النظم المستنسخة

النظام المستنسخ لإدارة المراجعة الموزعة يعتمد علي قاعدة بيانات مستنسخة. يكون الدخول مماثل للالتزام بالتوزيع. يخلق الالتزام الناجح خط أساسي واحد مما يقلل الحاجة إلي عمليات الدمج. مثال لنظام توزيع مستنسخ هو كود كو أوب Code Co-op

نموذج العمل

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

التاريخ

أول جيل نظام إدارة الإصدارات المركزية (DVCS) يتضمن جنو أرك ومونوتون. وبدأ الجيل الثاني بوصول (داركس) يتبعه استضافة نظم أخرى منها ميركوريال وجت التي تعتبر بديل لـ BitKeeper عندما لم يعد بالإمكان استخدامه مجانا بواسطة مشروع نواة لينكس وناشره. يتبعه بفترة قصيرة نظام بازار (GNU Bazaar). قبل ذلك كان يتم استخدام نظم إدارة الإصدارات المركزية (DVCS) المغلقة مثل Sun WorkShop TeamWare التي ألهمت BitKeeper والتي كانت تستخدم علي نطاق واسع في المشروعات.

المستقبل

بدأت بعض النظم المركزية الداخلية في اكتساب خصائص موزعة فمثلا أباتشي سبفيرجن قادر علي أداء عمليات عديدة بدون شبكة.[7] وقد يصبح الأمر أكثر صعوبة في الفصل بين النظم الموزعة داخليا والنظم المركزية هناك العديد من الأدوات التي تعتمد علي إدارة الإصدارات مثل برنامج ويكي ونظام الملفات ومحرر نصوص. وبعضها بدأ استخدام خصائص نظام إدارة الإصدارات المركزية (DVCS) لتتكامل مع خصائصه مثل نظم جازيست ويكي وإيكي ويكي.

انظر أيضًا

المراجع
  1. Wheeler, David، "Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems"، مؤرشف من الأصل في 26 نوفمبر 2018، اطلع عليه بتاريخ 8 مايو 2007.
  2. O'Sullivan, Bryan، "Distributed revision control with Mercurial"، مؤرشف من الأصل في 20 فبراير 2009، اطلع عليه بتاريخ 13 يوليو 2007.
  3. Spolsky, Joel (17 مارس 2010)، "Distributed Version Control is here to stay, baby"، Joel on Software، مؤرشف من الأصل في 27 نوفمبر 2016، اطلع عليه بتاريخ 18 يونيو 2010.
  4. "Ubuntu in Launchpad"، Canonical Ltd، مؤرشف من الأصل في 19 مايو 2019، اطلع عليه بتاريخ 21 أكتوبر 2008.
  5. Arnö, Kaj (19 يونيو 2008)، "Version Control: Thanks, BitKeeper - Welcome, Bazaar"، مؤرشف من الأصل في 15 نوفمبر 2010، اطلع عليه بتاريخ 19 يونيو 2008.
  6. "Getting Started/Sources/Amarok Git Tutorial"، KDE TechBase، كدي، 25 أغسطس 2009، مؤرشف من الأصل في 08 نوفمبر 2018، اطلع عليه بتاريخ 9 أكتوبر 2009، Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation.
  7. Subversion for CVS Users :: OSDir.com :: Open Source, Linux News & Software نسخة محفوظة 23 أغسطس 2016 على موقع واي باك مشين.
  • بوابة علم الحاسوب
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.