إدارة المراجعات revisions والإصدارات versions

نحن افترضنا أن عمليات تحرير العقد لن تكون عشوائية غير مترابطة بل قمنا بتركيز التحسين optimization عملية الإضافة في آخر الشجرة أو عبر الذهاب لعقدة ما بعملية seek ثم اسقاط شجرة عند عقدة بكل سلالتها ثم وضع النسخة المعدلة مكانها وهذا الأسلوب لا يمكن فيه أن تكون عمليات التحرير خارجة عن العقدة التي ذهبنا إليها بعملية seek أي أن الإضافة تكون للداخل في العمق ولا يجوز أن تكون بعمق أقل من الذي في أول عملية seek.

بكلمات أخرى قد تولد عملية الفرق مقاطع chunks لايمكن إضافتها بحركة seek واحدة لأن عملية إيجاد كل الأجداد لعقدة عملية مكلفة في نموذج البيانات الحالي فهي إما تأتي عبر عملية traverserWithStack او عبر عدد غير محدد من الاستعلامات على SQL في كل مرة نأخذ عقدة الأب حتى نصل إلى الجذر.

• علينا دراسة البنية الداخلية لنظام git خصوصا bare git repo - حيث أنها تمكن من الحصول على المحتويات الحالية وتأريخ التعديلات واستخراج المقارنات بشكل سريع مع أنها لا تحتوي أي مما سبق بشكل مباشر ومكرر كما أن حجمها صغير نسبيا.
• يجب تعريف الحد الأدنى من العمليات نسميها العمليات الذرية atomic opcodes تطبق على العقد أو على ما تحمل من وسوم أو على محتوياى العقدة …إلخ
  • delete - حذف مثلا حذف العقدة (دون سلالتها)
  • insert - إضافة (بعد العقدة السابقة وليس بالضرورة داخلها)
  • replace - وهي في الحقيقة مزاوجة ل delete ثم insert على نفس المكان
  • equal وتعني checkEqual - وتستخدم للتحقق من السياق
• يمكن الاستفادة من difflib في بايثون - علما أننا لا نحتاج إلى ? والوقت الضائع في البحث عنها أو توليدها لكن بأي حال يمكن تخصيص ذلك عبر get_opcodes أما get_grouped_opcodes التي تليها فهي تختزل من التقرير equal إلا بعض السياق فلا تعود السلسلة متصلة بل تصبح قائمة من المقاطع chunks وكل واحد عبارة عن قائمة من العمليات opcodes تبدأ وتنتهي بسياق من عملية equal.
• فكرة الاستعادة تكون بتطبيق ما هو مذكور لكن من الأخير (الأعلى إزاحة) إلى الأكثر حتى لا تتأثر الإزاحة المسجلة بعمليات الإضافة
• حيث أن نموذج البيانات الأدنى عبارة عن سلسلة مسطحة (يتم تركيبها منطقيا في شجرة هرمية) يمكن اعتباره سلسلة من العقد ويمكن تطبيق SequenceMatcher عليه مباشرة بكلمات أخرى لسنا بحاجة ل xml حيث يمكن أن تكون عملية diff عبارة عن جدول من opcodes.

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

وتوليد الفروقات يكون بطريقتين

أن تستلم دوال التعديل على العقد (مثل KitabCursor.appendNode أو dropDescendants أو Node.tagWith أو applyTags أو clearTags) معاملا جديدا اسمه revisions فإن لم يكن None فإنها تولد الفروقات عبره مما تملكه من معلومات.

يمكن اعتبار كل جدول في قاعدة البيانات على أنه سلسلة Sequence من الصفوف وتطبيق SequenceMatcher عليه بطريقة عمياء دون النظر إلى نموذج البيانات أو ال API وهذه تصلح في حال كان عندنا ملفين كل واحد نسخة من الكتاب ونريد الفرق بينهما.

الكائن Revisions يفترض أن يكون له طرق/دوال باسم كل عملية يتم استدعاء سلسلة منها لتسجيل تأريخ معين

rev.start(comment="fix broken url")
rev.op1()
rev.op2()
rev.end()

• العميات على جدول meta الخبيئ cached يمكن حفظ الجدول الجديد بالكامل لصغر الجدول.
• العمليات الأساسية على العقد (كل العميات الأخرى يمكن اعتبارها حذف ثم إضافة في أسوأ الأحوال)
  • حذف عقد (دون سلالتها لأننا ننظر لها وكأنها سلسلة كما في مفهوم SequenceMatcher)
  • إضافة عقد بعد عقدة ما - وهنا نحتاج تسجيل كل معلومات العقدة مثل depth و globalOrder ومعرف الأب والوسوم والمحتوى المباشر (أما المحتوى من العقد فهي عملية أخرى من عمليات إضافة العقد)
  • استبدال عقدة مكان عقدة وهنا علينا الانتباه أنه وفق مفهوم SequenceMatcher فإننا لن نحذف سلاسة العقد المتروكة. الفرق أنه في حالة الاستبدال علينا تسجيل الفروقات بين المحتويات وليس المحتوى الجديد.
• العمليات على الوسوم المطبقة على عقدة ما - بما أن الترتيب في الوسوم غير مهم فإن المطلوب هو تتبع
  • إضافة وسم جديد
  • حذف وسم
  • تعديل قيمة وسم موجود أصلا - وهنا ينطبق عليه ما ينطبق على المحتويات النصية من فرق diff العادي ولأن قيمة الوسم غالبا كلمة واحدة ربما من الأجدى فقط تسجيل القيمة الجديدة وليس diff
• محتوى العقدة النصي - فرق diff عادي بكلمات أخرى إن كنا نعمل استبدال لعقدة يمكننا أن نسجل الفرق في المحتوى المباشر.
• عمليات التوسعة والتضييق ل globalOrder وهنا نسجل عقدة البداية والنهاية ومقدار الإزاحة في globalOrder