svn - ترجمة - معنى كلمة عنوان بالانجليزي




ما الذي يجعل الدمج في DVCS سهلاً؟ (6)

قرأت في جويل على البرامج :

مع التحكم في إصدار الموزعة ، الجزء الموزع هو في الواقع ليس الجزء الأكثر إثارة للاهتمام.

الجزء المثير للاهتمام هو أن هذه الأنظمة تفكر من حيث التغييرات ، وليس من حيث الإصدارات.

وفي HgInit :

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

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

من خلال النظر إلى مجلد مستودع SVN ، لدي انطباع بأن Subversion تحافظ على كل التنقيحات مثل changeset . ومن خلال ما أعرفه ، يستخدم الزئبق كل من التغييرات واللقطات بينما يستخدم Git لقطة لتخزين البيانات.

إذا كان افتراضاتي صحيحًا ، فيجب أن تكون هناك طرق أخرى تجعل الدمج في DVCS سهلاً. ما هؤلاء؟

* تحديث:

  • أنا أكثر اهتماما بالمنظور الفني ، لكن الإجابات من منظور غير تقني مقبولة
  • التصحيحات:
    1. يعتمد نموذج مفاهيم جيت على اللقطات. يمكن تخزين اللقطات على هيئة لقطات من اللقطات الأخرى ، لكن الاختلافات هي فقط لتحسين التخزين. - تعليق رافائيل دوجيرد
  • من منظور غير فني:
    1. إنه ببساطة أمر ثقافي: لن يعمل DVCS على الإطلاق إذا كان الدمج صعباً ، لذلك يستثمر مطورو DVCS الكثير من الوقت والجهد في عملية الدمج. مستخدمو CVCS OTOH معتادون على الاندماج ، لذا لا يوجد حافز للمطورين لجعله يعمل. (لماذا نجعل شيئًا جيدًا عندما يدفع المستخدمون لك ما لا يقل عن جيدًا عن شيء هراء؟)
      ...
      للتلخيص: يتمثل الهدف الكامل من DVCS في وجود العديد من المستودعات اللامركزية ودمج التغييرات باستمرار ذهابًا وإيابًا. بدون دمج جيد ، فإن DVCS ببساطة عديمة الفائدة. ومع ذلك ، لا يزال بإمكان CVCS البقاء على قيد الحياة مع الدمج المزعج ، خاصة إذا كان البائع يستطيع تكييف مستخدميه لتجنب التجوال. - answer يورج دبليو ميتاج
  • من المنظور الفني:
    1. تسجيل DAG حقيقي من التاريخ يساعد! أعتقد أن الاختلاف الرئيسي هو أن CVCS لم تسجل دمجًا دائمًا كتغيير مع العديد من الآباء ، حيث فقدت بعض المعلومات. - comment tonfa
    2. بسبب دمج تتبع ، والحقيقة الأساسية أكثر أن كل التنقيقات يعرف والديها . ... عندما تقوم كل مراجعة (كل التزام) ، بما في ذلك الدمج ، تعرف والديها (لارتكاب الدمج الذي يعني وجود / تذكر أكثر من أحد الوالدين ، أي دمج الدمج) ، يمكنك إعادة بناء الرسم التخطيطي (DAG = الرسم البياني الدائري غير المباشر) للمراجعة التاريخ. إذا كنت تعرف الرسم البياني للمراجعات ، يمكنك العثور على سلف مشترك للالتزامات التي تريد دمجها. وعندما يعرف DVCS نفسه كيفية العثور على سلف مشترك ، لا تحتاج إلى تقديمه كحجة ، على سبيل المثال في CVS.
      .
      لاحظ أنه قد يكون هناك أكثر من سلف مشترك لعملين (أو أكثر). تستفيد Git مما يسمى استراتيجية الدمج "العودية" ، التي تدمج قواعد الدمج (السلف المشترك) ، حتى يتم تركك مع سلف مشترك افتراضي / فعال (في بعض التبسيط) ، ويمكن أن تقوم بعملية دمج 3 خطوات بسيطة. - إجابة ياكوب ناربسكي

تحقق كذلك كيف و / أو لماذا يتم دمج في Git أفضل من SVN؟


أعتقد أن مجموعة DAG من changesets ، كما ذكر من قبل الآخرين ، تحدث فرقا كبيرا. DVCS: ess تتطلب انقسام التاريخ (ودمج) على مستوى أساسي ، في حين افترض CVCS: es (وهي أقدم) حيث تم بناؤها من اليوم الأول لتتبع المراجعات والملفات أولاً ، مع إضافة دعم الدمج على أنه فكرة لاحقة.

وبالتالي:

  • يسهل الدمج والتتبع عندما يتم تتبع العلامات / الفروع بشكل منفصل عن شجرة مصادر المصادر ، بحيث يمكن دمج الريبو بأكمله دفعة واحدة.
  • نظرًا لأن DVCS: يحتوي على repos محلي ، فهذه سهلة الإنشاء ، لذلك يتبين أنه من السهل الاحتفاظ بوحدات مختلفة في repos مختلفة بدلاً من تتبعها كلها داخل repo كبير. (لذلك لا تسبب عمليات الدمج على مستوى الريبو نفس الاضطرابات كما هي في svn / cvs حيث غالباً ما يحتوي أحد repo على العديد من الوحدات غير ذات الصلة التي تحتاج إلى تاريخ دمج منفصل.)
  • يسمح CVS / SVN لملفات مختلفة في دليل العمل بأن تأتي من مراجعات مختلفة ، في حين أن DVCS: es عادة ما يكون هناك مراجعة واحدة لكامل برنامج WC ، دائمًا (أي حتى إذا تمت إعادة الملف إلى إصدار سابق ، فسوف يظهر كما تم تعديله في في حالة اختلافه عن الملف في النسخة التي تم سحبها ، ولا يعرض SVN / CVS هذا دائمًا.)

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

لذلك ، تلخيص:

  • DVCS: تحتاج إلى دمجات سهلة ، لديك مجموعة الميزات الخاصة بهم على أساس ذلك. يتم اتخاذ قرار التصميم بحيث يتم القيام بهذه الخطوات بسهولة وتتبع (عبر DAG) ، ويتم تنفيذ ميزات أخرى (فروع / علامات / وحدات فرعية) لتلائم ذلك ، وليس العكس.
  • CVCS: كان لديه بعض الميزات من البداية (مثل الوحدات) التي جعلت بعض الأشياء سهلة ، ولكن جعل دمج على مستوى الريبو صعبة للغاية لتنفيذ.

على الأقل هذا هو ما أشعر به من تجربتي مع السيرة الذاتية ، svn ، بوابة و hg. (من المحتمل أن يكون هناك ملفات CVCS: es التي حصلت على هذا الشيء أيضًا.)


جزء من السبب هو بالطبع الحجة الفنية بأن DVCSes يخزن معلومات أكثر مما يفعله SVN (DAG ، نسخ) ، ولديه أيضًا نموذج داخلي أبسط ، وهذا هو السبب في أنه قادر على تنفيذ عمليات دمج أكثر دقة ، كما هو مذكور في الردود الأخرى .

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

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

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

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

وإذا تبين أن هناك نزاعًا ، يمكنك أن تقرر تأجيل الدمج وأن تفعل ذلك في وقت فراغك الخاص. هذا على وجه الخصوص يجعل من دمج أقل بكثير مزعج.


في Git ودمج DVCS الآخر ليس سهلاً بسبب سلسلة غامضة من عرض changesets (إلا إذا كنت تستخدم Darcs ، مع نظريته من البقع ، أو بعض DVCS مستوحاة من Dcss ؛ فهي الأقلية ، على الرغم من ذلك) أن Joel يتجول ، ولكن بسبب من دمج تتبع ، والحقيقة الأساسية أكثر أن كل التنقيقات يعرف والديها . لذلك أنت بحاجة (على ما أظن) يلتزم كل الشجرة / كامل المستودع ... الذي يحد لسوء الحظ القدرة على القيام بعمليات السحب الجزئية ، وجعل ارتكاب حول مجموعة فرعية فقط من الملفات.

عند مراجعة كل مراجعة (كل التزام) ، بما في ذلك الدمج ، تعرف والديها (لارتكاب الدمج الذي يعني وجود / تذكر أكثر من أحد الوالدين ، أي دمج الدمج ) ، يمكنك إعادة تخطيط الرسم التخطيطي (DAG = الرسم البياني الدائري المباشر) من سجل النُسخ السابقة. إذا كنت تعرف الرسم البياني للمراجعات ، يمكنك العثور على سلف مشترك للالتزامات التي تريد دمجها. وعندما يعرف DVCS نفسه كيفية العثور على سلف مشترك ، لا تحتاج إلى تقديمه كحجة ، على سبيل المثال في CVS.

لاحظ أنه قد يكون هناك أكثر من سلف مشترك لعملين (أو أكثر). تستفيد Git مما يسمى استراتيجية الدمج "العودية" ، التي تدمج قواعد الدمج (السلف المشترك) ، حتى يتم تركك مع سلف مشترك افتراضي / فعال (في بعض التبسيط) ، ويمكن أن تقوم بعملية دمج 3 خطوات بسيطة.

تم إنشاء استخدام Git للكشف عن إعادة تسمية لتكون قادرة على التعامل مع عمليات الدمج التي تنطوي على إعادة تسمية الملف. (هذا يدعم حجة Jörg W Mittag بأن دمج DVCS هو دعم أفضل لأنهم كانوا بحاجة إلى الحصول عليه ، حيث أن الدمج أكثر شيوعًا عنه في CVCS مع دمجه مخبأ في أمر 'update' ، في سير عمل التحديث ثم الالتزام ، cf Understanding Version التحكم (WIP) بواسطة Eric S. Raymond).


قد يكون مستخدمو DVCS لا يفعلون أبداً الأشياء التي تجعل الدمج بجد مثل decactorings التي تغير وإعادة تسمية / نسخ معظم الملفات في المشروع ، أو إعادة تصميم من واجهات برمجة التطبيقات التي تستخدم في hundrends الملفات.


كملاحظة تاريخية ، فإن نظام PRCS القديم PRCS يعرف أيضًا عن الأسلاف المشتركة ويمكنه الدمج بكفاءة ، على الرغم من أنه لم يتم توزيعه (تم إنشاؤه في أعلى ملفات RCS!). وهذا يعني أنه يمكن ترحيلها بفعالية إلى بوابة مع الاحتفاظ بالتاريخ.


لا يوجد شيء على وجه الخصوص في DVCS التي تجعل دمج أسهل. إنه ببساطة أمر ثقافي: لن يعمل DVCS على الإطلاق إذا كان الدمج صعباً ، لذلك يستثمر مطورو DVCS الكثير من الوقت والجهد في عملية الدمج. مستخدمو CVCS OTOH معتادون على الاندماج ، لذا لا يوجد حافز للمطورين لجعله يعمل. (لماذا نجعل شيئًا جيدًا عندما يدفع المستخدمون لك ما لا يقل عن جيدًا عن شيء هراء؟)

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

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

وعندما يجربون DVCS ، فإنهم ينسبون كل الخير إلى الجزء "D".

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

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

لذا ، تمامًا مثل كل شيء آخر في هندسة البرمجيات ، إنها مسألة جهد.







dvcs