مقارنة بين أنظمة التحكم في الإصدار المركزي والموزع [مغلق]

Question

ما هي مزايا وعيوب مع استخدام المركزية مقابل الموزعة أنظمة التحكم في الإصدار (DVCS)؟هل واجهت أي مشاكل في DVCS وكيف قمت بالحماية من هذه المشاكل؟ حافظ على أداة المناقشة حيادية ومشتعلة إلى الحد الأدنى.

بالنسبة لأولئك الذين يتساءلون عن أدوات DVCS المتاحة، إليك قائمة بأفضل أدوات DVCS المجانية/مفتوحة المصدر المعروفة:

• شخص سخيف, ، (مكتوبة في C) يستخدمها نواة لينكس وروبي أون ريلز.
• زئبقي, ، (مكتوب بلغة بايثون) يستخدمه موزيلا وOpenJDK.
• بازار, ، (مكتوب بلغة بايثون) يستخدمه مطوري أوبونتو.
• داركس, (مكتوب في هاسكل).

Answer 1

من إجابتي إلى مختلف سؤال:

تحل أنظمة التحكم في الإصدار الموزع (DVCSS) مشاكل مختلفة عن VCSS المركزية.مقارنتها مثل مقارنة المطارق والفكات.

مركزية VCS تم تصميم الأنظمة بقصد وجود مصدر حقيقي واحد مبارك ، وبالتالي جيد.يعمل جميع المطورين (الخروج) من هذا المصدر ، ثم يضيفون (ارتكاب) تغييراتهم ، والتي تصبح بعد ذلك بالمثل.الفرق الحقيقي الوحيد بين CVS ، التخريب ، Clearcase ، Perforce ، VisualSourceSafe وجميع CVCSS الأخرى هو في سير العمل والأداء والتكامل الذي يقدمه كل منتج.

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

الخيار الحقيقي بين استخدام نوع واحد أو الآخر هو تنظيمي-إذا كان مشروعك أو مؤسستك يريد التحكم المركزي ، فإن DVCS هو غير مستمر.إذا كان من المتوقع أن يعمل مطوراتك في جميع أنحاء البلاد/العالم ، دون اتصالات آمنة النطاق العريض بمستودع مركزي ، فمن المحتمل أن يكون DVCs خلاصك.إذا كنت بحاجة إلى كليهما ، فأنت FSCK'D.

Answer 2

بالنسبة لأولئك الذين يعتقدون أن الأنظمة الموزعة لا تسمح بنسخ موثوقة ، يرجى ملاحظة أن هناك الكثير من الأماكن التي تحتوي فيها الأنظمة الموزعة على نسخ موثوقة ، ومن المحتمل أن يكون المثال المثالي شجرة Kernel Linus.من المؤكد أن الكثير من الناس لديهم أشجارهم الخاصة ولكن جميعهم يتدفقون نحو شجرة لينوس.

ومع ذلك ، اعتدت أن أظن أن SCM الموزعة كانت مفيدة فقط للعديد من المطورين الذين يقومون بأشياء مختلفة ، لكن قرر مؤخرًا أن أي شيء يمكن أن يقوم به مستودع مركزي يمكن أن يفعله المرء بشكل أفضل.

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

من خلال الريبو الموزعة ، يمكنك الذهاب في العمل كالمعتاد ، والالتزام ، والمضي قدمًا ، عندما يكون لديك وصول صافي مرة أخرى ، فأنت تضغط على "repo true One One" ولم يتغير شيء.

ناهيك عن الشيء الجميل الآخر حول اتفاقيات إعادة الشراء الموزعة:التاريخ الكامل متاح دائما.تحتاج إلى إلقاء نظرة على سجلات المراجعة عندما تكون بعيدًا عن الشبكة؟تحتاج إلى شرح المصدر لمعرفة كيف تم تقديم خطأ؟كل ذلك ممكن مع اتفاقات إعادة الشراء الموزعة.

من فضلك لا تصدق أن الموزعة مقابل المركزية تدور حول الملكية أو النسخ الموثوقة أو أي شيء من هذا القبيل.يتم توزيع الواقع هو الخطوة التالية في تطور SCM.

Answer 3

ليست مقارنة حقًا، ولكن إليك ما تستخدمه المشاريع الكبيرة:

مراكز VCS المركزية

• التخريب

  أباتشي، دول مجلس التعاون الخليجي، روبي، MPlayer، Zope، Plone، Xiph، FreeBSD، WebKit، ...

• CVS

  CVS

VCSes الموزعة

• شخص سخيف

  Linux kernel، KDE، Perl، Ruby on Rails، Android، Wine، Fedora، X.org، Mediawiki، Django، VLC، Mono، Gnome، Samba، CUPS، GnuPG، Emacs ELPA...

• زئبق (زئبق)

  Mozilla وMozdev، OpenJDK (Java)، OpenSolaris، ALSA، NTFS-3G، Dovecot، MoinMoin، mutt، PETSc، Octave، FEniCS، Aptitude، Python، XEmacs، Xen، Vim، Xine...

• bzr

  إيماكس، أبت، ميلمان، ماي إس كيو إل، سكويد، ...تمت ترقيته أيضًا داخل Ubuntu.

• داركس

  جي إتش سي، أيون، xmonad، ...مشهورة داخل مجتمع هاسكل.

• حفرية

  سكليتي

Answer 4

دبليو.كريج تريدر قال هذا عن DVCS وCVCS:

إذا كنت بحاجة إلى كليهما، فأنت في حاجة إلى ذلك.

لن أقول أنك كذلك fsck'd عند استخدام كليهما.عمليًا، يحاول المطورون الذين يستخدمون أدوات DVCS عادةً دمج تغييراتهم (أو إرسال طلبات السحب) في موقع مركزي (عادةً إلى فرع الإصدار في مستودع الإصدار).هناك بعض السخرية مع المطورين الذين يستخدمون DVCS ولكن في النهاية يلتزمون بسير عمل مركزي، يمكنك أن تبدأ في التساؤل عما إذا كان النهج الموزع أفضل حقًا من النهج المركزي.

هناك بعض المزايا مع DVCS مقارنة بـ CVCS:

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

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

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

…وبعض العيوب التي عادةً ما يكون لها حلول بديلة:

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

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

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

Answer 5

أثناء بحثي عن SCM المناسب، وجدت الروابط التالية مفيدة جدًا:

1. مبادرة أفضل لإدارة سلسلة التوريد:مقارنة.مقارنة حوالي 26 نظام تحكم في الإصدار.
2. مقارنة برامج التحكم بالمراجعة.مقالة ويكيبيديا تقارن حوالي 38 نظامًا للتحكم في الإصدار تغطي موضوعات مثل الاختلافات التقنية والميزات وواجهات المستخدم والمزيد.
3. أنظمة التحكم في الإصدار الموزع.مقارنة أخرى، لكنها ركزت بشكل أساسي على الأنظمة الموزعة.

Answer 6

وإلى حد ما، فإن المخططين متساويان:

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

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

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

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

Answer 7

تعد VCS الموزعة جذابة بعدة طرق، ولكن أحد العيوب التي ستكون مهمة لشركتي هو مسألة إدارة الملفات غير القابلة للدمج (عادةً ما تكون ثنائية، على سبيل المثال.وثائق اكسل).يتعامل Subversion مع هذا من خلال دعم خاصية "svn:needs-lock"، مما يعني أنه يجب عليك الحصول على قفل للملف غير القابل للدمج قبل تحريره.أنه يعمل بشكل جيد.لكن تدفق العمل يتطلب نموذج مستودع مركزي، وهو ما يتعارض مع مفهوم DVCS.

لذا، إذا كنت تريد استخدام DVCS، فهو ليس مناسبًا حقًا لإدارة الملفات غير القابلة للدمج.

Answer 8

لقد كنت أستخدم التخريب لسنوات عديدة الآن وكنت سعيدًا به حقًا.

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

يمكن إعداد أي أقراص رقمية رقمية باستخدام خادم مركزي، ولكن ما تحصل عليه هو من بين أشياء أخرى

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

ويمكنك العمل بدون شبكة.

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

للخروج من Git : http://git-scm.com/
للخروج الأحفوري: http://www.fossil-scm.org
للخروج من Mercurial : https://www.mercurial-scm.org

الآن، يمكنني فقط أن أوصي بأنظمة dvcs، ويمكنك بسهولة استخدام خادم مركزي

Answer 9

المشكلة الرئيسية (بصرف النظر عن مشكلة النطاق الترددي الواضحة) هي ملكية.

وذلك للتأكد من أن الموقع (الجغرافي) المختلف لا يعمل على نفس العنصر عن الآخر.

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

للإجابة على تعليقات هذه الإجابة، فأنت تريد حقًا أن تخبرك الأداة بمن يملك ماذا، و ثم التواصل (من خلال الهاتف أو الرسائل الفورية أو البريد) مع الموقع البعيد.
إذا لم تكن لديك آلية ملكية...سوف "تتواصل"، ولكن في كثير من الأحيان بعد فوات الأوان؛) (أي:بعد القيام بالتطوير المتزامن على مجموعة مماثلة من الملفات في نفس الفرع.يمكن أن يصبح الالتزام فوضويًا)

Answer 10

بالنسبة لي، هذه مناقشة أخرى حول الذوق الشخصي ومن الصعب أن أكون موضوعيًا حقًا.أنا شخصيا أفضل زئبقي على DVCS الأخرى.أحب أن أكتب الخطافات بنفس اللغة زئبقي هو مكتوب في والحمل الأصغر للشبكة - فقط لأقول بعض الأسباب الخاصة بي.

Answer 11

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

Answer 12

لدي شعور بأن Mercurial (وغيرها من DVCS) أكثر تطوراً من تلك المركزية.على سبيل المثال، دمج فرع في Mercurial يحتفظ بالسجل الكامل للفرع بينما في SVN عليك الذهاب إلى دليل الفرع لرؤية السجل.

Answer 13

ميزة أخرى لـ SCM الموزعة حتى في سيناريو المطور الفردي هي إذا كان لديك، مثل الكثير منا، أكثر من جهاز واحد تعمل عليه.

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

1. موفر للوقت، خاصة مع مفاتيح ssh
2. طريقة لتقسيم الاختلافات بين الأنظمة المختلفة (على سبيل المثال.Red Hat vs Debian ، BSD vs Linux ، إلخ)

Answer 14

دبليو.تلخص إجابة Craig Trader معظمها، ومع ذلك، أجد أن أسلوب العمل الشخصي يُحدث فرقًا كبيرًا أيضًا.في المكان الذي أعمل فيه حاليًا، نستخدم التخريب كمصدر حقيقي واحد لدينا، ومع ذلك، يستخدم العديد من المطورين git-svn على أجهزتهم الشخصية للتعويض عن مشكلة سير العمل التي نواجهها (فشل الإدارة، ولكن هذه قصة أخرى).على أي حال.يتعلق الأمر حقًا بالموازنة بين مجموعات الميزات التي تجعلك أكثر إنتاجية مع ما تحتاجه المؤسسة (المصادقة المركزية، على سبيل المثال).

Answer 15

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

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