دمج (التحكم في الإصدار)

تعتمد عملية الدمج غير المنظم على النصوص الخام، وتستخدم عادةً أسطر النص كوحدات أساسية. هذا ما تستخدمه أدوات يونكس (مثل diff/patch) وأدوات CVS (مثل SVN وGit). إلا أن هذه الطريقة محدودة ، إذ لا يُمثل سطر النص بنية شفرة المصدر.

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

تُجرى عملية دمج ثلاثي بعد تحليل آلي للاختلافات بين الملف "أ" والملف "ب"، مع مراعاة الأصل، أو السلف المشترك، للملفين "ج". وهي طريقة دمج تقريبية، لكنها قابلة للتطبيق على نطاق واسع لأنها لا تتطلب سوى سلف مشترك واحد لإعادة بناء التغييرات المراد دمجها. يمكن إجراء الدمج الثلاثي على نص خام (سلسلة من الأسطر) أو على أشجار مُهيكلة. ^{[ 2 ]}

يبحث دمج البيانات الثلاثي عن المقاطع المتطابقة في ملفين فقط من الملفات الثلاثة. في هذه الحالة، توجد نسختان من المقطع، ويتم تجاهل النسخة الموجودة في الملف الأصلي المشترك "C"، بينما تُحفظ النسخة المختلفة في الناتج. إذا تطابقت النسختان "A" و"B"، فستظهر النسخة المتطابقة في الناتج. أما المقطع المتطابق في "A" و"C" فيُخرج النسخة المُعدّلة في "B"، والعكس صحيح.

يتم وضع علامة على الأقسام المختلفة في الملفات الثلاثة باعتبارها حالة تعارض، ويترك الأمر للمستخدم لحلها.

يُنفَّذ دمج الملفات الثلاثي بواسطة برنامج diff3 واسع الانتشار ، وكان هذا الابتكار المحوري الذي سمح بالانتقال من أنظمة التحكم في المراجعات القائمة على قفل الملفات إلى أنظمة التحكم في المراجعات القائمة على الدمج. ويُستخدم على نطاق واسع في نظام الإصدارات المتزامنة (CVS).

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

هناك حالات محرجة، لا سيما "الدمج المتقاطع"، ^{[ 3 ]} حيث لا يوجد سلف مشترك وحيد للإصدارات المعدلة.

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

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

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

التصحيح هو ملف يحتوي على وصف للتغييرات التي طرأت على ملف. في بيئة يونكس، جرت العادة على نشر التغييرات التي تُجرى على الملفات النصية على شكل تصحيحات بالصيغة التي ينتجها الأمر " diff -u". يمكن لبرنامج التصحيح استخدام هذه الصيغة لإعادة تطبيق التغييرات (أو إزالتها) من ملف نصي، أو من بنية مجلدات تحتوي على ملفات نصية.

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

كما بدأ نظام CVS كمجموعة من البرامج النصية على diff3 ، بدأ نظام GNU arch كمجموعة من البرامج النصية على patch. مع ذلك، يُعد تطبيق التصحيحات غير الدقيق طريقة غير موثوقة نسبيًا، إذ قد يُطبّق أحيانًا تصحيحات تفتقر إلى السياق الكافي (خاصةً تلك التي تُنشئ ملفًا جديدًا)، وقد يرفض أحيانًا تطبيق عمليات الحذف التي أجراها كلا النظامين المشتقين.

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

يتطلب تبديل التصحيحات تخزين التغييرات الدقيقة التي أدت إلى إنشاء الملفات المشتقة أو إمكانية استعادتها. ومن خلال هذه التغييرات الدقيقة، يمكن حساب كيفية تعديل أحدها لإعادة بنائه على الآخر. على سبيل المثال، إذا أضاف التصحيح A السطر "X" بعد السطر 7 من الملف F، وأضاف التصحيح B السطر "Y" بعد السطر 310 من الملف F، فيجب إعادة كتابة B إذا أُعيد بناؤه على A: يجب إضافة السطر في السطر 311 من الملف F، لأن السطر المضاف في A يُزيح أرقام الأسطر بمقدار واحد.

لقد حظي تبديل الرقع بدراسة أكاديمية واسعة، إلا أن خوارزميات معالجة تعارضات الدمج في هذا النوع من التبديل لا تزال موضع تساؤل بحثي. ومع ذلك، فقد ثبت أن تبديل الرقع يُنتج نتائج دمج "صحيحة" ^{[ 4 ]،} بينما تعتمد استراتيجيات الدمج الأخرى في الغالب على أساليب استدلالية تسعى إلى إنتاج ما يرغب المستخدمون برؤيته.

يقوم برنامج Unix flipdiffمن حزمة "patchutils" بتنفيذ عملية تبديل التصحيحات للتصحيحات التقليدية التي يتم إنتاجها بواسطة diff -u.

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

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

تُرتّب الأسطر بحيث يأتي كل سطر بعد جميع الأسطر التي سبقته في مرحلة ما من التاريخ، وقبل جميع الأسطر التي تلته في مرحلة ما من التاريخ. إذا لم تُؤدِّ هذه القيود إلى ترتيب كلي لجميع الأسطر، فإن الأسطر التي لا يوجد لها ترتيب بالنسبة لبعضها البعض تُعتبر إضافات متعارضة.

يبدو أن دمج Weave كان مستخدمًا في أداة التحكم في الإصدارات التجارية BitKeeper، وهو قادر على معالجة بعض الحالات الإشكالية التي ينتج عنها دمج ثلاثي الاتجاهات نتائج خاطئة أو غير سليمة. كما أنه أحد خيارات الدمج في أداة التحكم في الإصدارات GNU Bazaar ، ويُستخدم أيضًا في Codeville.