Порівняння між централізованою та розподіленою системами контролю версій [закрито]

Які переваги та недоліки використання централізованих та розподілених систем контролю версій (DVCS)? Чи не стикалися з якимись проблемами у DVCS і як ви захищалися від цих проблем? Зведіть інструмент обговорення агностичним і палаючим до мінімуму.

Для тих, хто цікавиться, які інструменти DVCS доступні, ось список найвідоміших безкоштовних / з відкритим кодом DVCS:

• Git , (написаний на C), який використовується ядром Linux та Ruby on Rails .
• Mercurial , (написаний на Python), що використовується Mozilla та OpenJDK .
• Bazaar (написаний на Python), який використовується розробниками Ubuntu .
• Дарч , (написано Хаскеллом ).

З моєї відповіді на інше запитання :

Розподілені системи контролю версій (DVCS) вирішують інші проблеми, ніж централізовані VCS. Порівнювати їх - це все одно, що порівнювати молотки та викрутки.

Централізовані системи VCS розроблені з метою встановити Єдине Справжнє Джерело, яке є Благословенним і, отже, Добрим. Усі розробники працюють (оформляють замовлення) з цього джерела, а потім додають (фіксують) свої зміни, які потім стають подібним чином благословенними. Єдина реальна різниця між CVS, Subversion, ClearCase, Perforce, VisualSourceSafe та усіма іншими CVCS є у робочому процесі, продуктивності та інтеграції, які пропонує кожен продукт.

Розподілені системи VCS розроблені з наміром, щоб одне сховище було таким же хорошим, як і будь-яке інше, і що злиття з одного сховища в інше є лише іншою формою спілкування. Будь-яке семантичне значення щодо того, якому сховищу слід довіряти, накладається зовні процесом, а не самим програмним забезпеченням.

Реальним вибором між використанням одного типу або іншого є організаційний - якщо ваш проект або організація хоче централізоване управління, тоді DVCS не є початком. Якщо від ваших розробників очікується робота по всій країні / світі, без безпечних широкосмугових з’єднань із центральним сховищем, то DVCS - це, мабуть, ваше порятунок. Якщо вам потрібне і те, і інше, вам потрібно.

Тим, хто вважає, що розподілені системи не дозволяють авторитетних копій, зауважте, що є багато місць, де розподілені системи мають авторитетні копії, ідеальним прикладом є, мабуть, дерево ядра Лінуса. Звичайно, у багатьох людей є власні дерева, але майже всі вони пливуть до дерева Лінуса.

Тим не менш, я звик думати, що розподілені SCM були корисні лише для багатьох розробників, які роблять різні речі, але нещодавно вирішили, що все, що може зробити централізоване сховище розподіленого, може зробити краще.

Наприклад, скажімо, що ви сольний розробник, який працює над власним особистим проектом. Централізоване сховище може бути очевидним вибором, але враховуйте цей сценарій. Ви знаходитесь далеко від доступу до мережі (в літаку, у парку тощо) і хочете працювати над своїм проектом. У вас є ваша локальна копія, щоб ви могли нормально працювати, але ви дійсно хочете зафіксувати, оскільки ви закінчили одну функцію і хочете перейти до іншої, або ви знайшли помилку, яку потрібно виправити, або щось інше. Справа в тому, що при централізованому репо ви в кінцевому підсумку або змішуєте всі зміни разом і фіксуєте їх у нелогічному наборі змін, або вручну розбиваєте їх пізніше.

З розподіленим репо ви продовжуєте працювати як зазвичай, фіксуєтесь, рухаєтесь далі, коли у вас знову є мережевий доступ, ви натискаєте на свій "один справжній репо", і нічого не змінюється.

Не кажучи вже про іншу приємну річ щодо розподілених репозиторіїв: повна історія доступна завжди. Вам потрібно переглянути журнали виправлень, коли далеко від мережі? Вам потрібно анотувати джерело, щоб побачити, як була введена помилка? Все можливо з розподіленими репо.

Будь ласка, не вірте, що розподілене проти централізованого стосується права власності, авторитетних копій чи чогось подібного. Поширеність реальності - це наступний крок в еволюції СКМ.

Не дуже порівняння, але ось що використовують великі проекти:

Централізовані VCS

• Підривна діяльність

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

Розподілені VCS

• git

  Ядро Linux, 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

  Emacs, Apt, Mailman, MySQL, Squid, ... також рекламуються в Ubuntu.

• дарків

  ghc, ion, xmonad, ... популярні серед спільноти Haskell.

• викопні

  SQLite

В. Крейг Трейдер сказав про DVCS та CVCS:

Якщо вам потрібне і те, і інше, вам потрібно.

Я б не сказав, що ти fsck'd коли використовуєте обидва. Практично розробники, які використовують інструменти DVCS, зазвичай намагаються об'єднати свої зміни (або надіслати запити на витягування) із центральним розташуванням (зазвичай до гілки випуску у сховищі випусків). Є деяка іронія у розробників, які використовують DVCS, але врешті-решт дотримуйтесь централізованого робочого процесу, ви можете почати гадати, чи дійсно розподілений підхід краще, ніж централізований.

У DVCS є кілька переваг перед CVCS:

• Поняття унікально впізнаваних комітів робить надсилання патчів між однолітками безболісним. Тобто ви робите виправлення як коміт і ділитесь ним з іншими розробниками, яким це потрібно. Пізніше, коли всі хочуть об'єднатися разом, цей конкретний коміт розпізнається і може бути порівняний між гілками, маючи менше шансів на конфлікт об'єднання. Розробники, як правило, надсилають патчі один одному USB-накопичувачем або електронною поштою, незалежно від використовуваного вами інструменту встановлення версій. На жаль, у випадку CVCS, контроль версій реєструє коміти як окремі, не визнаючи, що зміни однакові, що призводить до вищих шансів конфлікту злиття.

• Ви можете мати локальні експериментальні гілки (клоновані сховища також можна вважати гілкою), які вам не потрібно показувати іншим. Це означає, що порушення змін не повинно впливати на розробників, якщо ви нічого не просунули вгору. У CVCS, коли у вас все ще є важка зміна, можливо, вам доведеться працювати в автономному режимі, поки ви не виправите це і не внесете зміни до того часу. Цей підхід фактично перемагає мету використання версій як захисної мережі, але це необхідне зло в CVCS.

• У сучасному світі компанії зазвичай працюють з офшорними розробниками (або, якщо навіть краще, вони хочуть працювати вдома). Наявність DVCS допомагає цим проектам, оскільки це позбавляє від необхідності надійного підключення до мережі, оскільки кожна людина має власні репо.

... і деякі недоліки, які зазвичай мають обхідні шляхи:

• Хто має останню версію? У CVCS магістраль зазвичай має останню версію, але в DVCS це може бути не зовсім очевидним. Обхідний шлях полягає у використанні правил поведінки, згідно з якими розробники проекту повинні домовитись про репо, щоб об'єднати свою роботу.

• Песимістичні блокування, тобто файл блокується під час оформлення виїзду, зазвичай неможливі через паралельність, яка може трапитися між сховищами у DVCS. Причина блокування файлів існує у контролі версій тому, що розробники хочуть уникнути конфліктів злиття. Однак блокування має недолік уповільнення розробки, оскільки два розробники не можуть одночасно працювати над одним і тим же фрагментом коду, як із довгою моделлю транзакції, і це не є повною гарантією проти конфліктів злиття. Єдиним розумним способом, незалежно від контролю версій, є боротьба з великими конфліктами злиття - це мати хорошу архітектуру коду (наприклад, низьке зчеплення з високою згуртованістю) і розподілити свої робочі завдання так, щоб вони мали незначний вплив на код (що простіше сказати, ніж зробити) .

• У власних проектах було б згубно, якби ціле сховище стало публічно доступним. Навіть більше, якщо незадоволений або зловмисний програміст потрапляє до клонованого сховища. Витоки вихідного коду є серйозним болем для власницького бізнесу. DVCS робить це просто, оскільки потрібно лише клонувати сховище, тоді як деякі системи CM (наприклад, ClearCase) намагаються обмежити цей доступ. Однак, на мій погляд, якщо у вас є достатня кількість дисфункціональних можливостей у культурі вашої компанії, то жоден контроль версій у світі не допоможе вам проти витоку вихідного коду.

Під час пошуку правильного SCM я знайшов такі посилання як велику допомогу:

1. Краща ініціатива СКМ: Порівняння . Порівняння близько 26 систем контролю версій.
2. Порівняння програмного забезпечення для контролю версій . Стаття у Вікіпедії, що порівнює близько 38 систем контролю версій, що охоплюють такі теми, як технічні відмінності, функції, користувальницькі інтерфейси тощо.
3. Розподілені системи контролю версій . Ще одне порівняння, але основна увага приділяється розподіленим системам.

Певною мірою дві схеми еквівалентні:

• Розподілений VCS може тривіально емулювати централізований, якщо ви завжди завжди надсилаєте свої зміни до якогось призначеного сховища вище за течією після кожного локального коміту.
• Централізований VCS зазвичай не може наслідувати розподілений так само природно, але ви можете отримати щось дуже подібне, якщо використовувати щось на зразок ковдри поверх нього. Ковдра, якщо ви не знайома з нею, - це інструмент для управління великими наборами патчів поверх якогось попереднього проекту. Ідея тут полягає в тому, що команда коміту DVCS реалізується шляхом створення нового патча, а команда push реалізується шляхом фіксації кожного непогашеного патчу до централізованого VCS, а потім відкидання файлів патчів. Це звучить трохи незручно, але на практиці насправді це працює досить добре.

Сказавши це, є кілька речей, які DVCS традиційно роблять дуже добре і які більшість централізованих VCS роблять трохи хешу. Найважливішим з них є, мабуть, розгалуження: DVCS полегшить розгалуження сховища або об’єднання гілок, які більше не потрібні, і буде відстежувати історію, поки ви це робите. Немає особливої ​​причини, чому централізована схема мала б із цим проблеми, але історично, схоже, ще ніхто не все зрозумів. Чи насправді це проблема для вас, залежить від того, як ви збираєтеся організувати розвиток, але для багатьох людей це є суттєвим фактором.

Інша позитивна перевага DVCS є те, що вони працюють в автономному режимі. Я ніколи насправді не надто цим користувався; Здебільшого я розробляю або в офісі (тобто сховище знаходиться в локальній мережі), або вдома (отже, є ADSL). Якщо ви багато займаєтесь розробкою ноутбуків під час подорожей, це може бути для вас більшою увагою.

Насправді не так багато прийомів, характерних для DVCS. Існує дещо більша тенденція до тих, що люди заспокоюються, тому що ви можете вчиняти дії, не натискаючи, і в кінцевому підсумку легко полірувати речі приватно, але крім цього, у нас не було дуже багато проблем. Це може бути тому, що ми маємо значну кількість розробників із відкритим кодом, які зазвичай знайомі з моделлю розробки патчів для торгівлі виправленнями, але вхідні розробники із закритим кодом також, здається, підбирають речі досить швидко.

Я використовую диверсію вже багато років і був по-справжньому задоволений.

Потім почався кайф GIT, і мені просто довелося його перевірити. І для мене головним пунктом продажу було розгалуження. О, малюк. Тепер мені більше не потрібно чистити свій репозиторій, повертатися назад до декількох версій або будь-якого безглуздого, що я робив під час використання subversion. У dvcs все дешево. Хоча я пробував лише викопні та git, але я використовував perforce, cvs та subversion, і схоже, що у dvcs всі справді дешеві розгалуження та мічення. Більше не потрібно копіювати весь код на одну сторону, і тому злиття - це просто вітер.

Будь-які dvcs можна налаштувати за допомогою центрального сервера, але ви отримуєте серед іншого

Ви можете перевірити будь-яку незначну зміну, яка вам подобається, як каже Лінус, якщо вам потрібно використати більше одного речення для опису того, що ви щойно зробили, ви робите занадто багато. Ви можете по-своєму попрацювати з кодом, гілкою, об’єднати, клонувати та протестувати все локально, не заставляючи нікого завантажувати величезну кількість даних. І вам потрібно лише просунути остаточні зміни на центральний сервер.

І ви можете працювати без мережі.

Тож коротше, використання контролю версій - це завжди добре. Використання dvcs дешевше (в КБ та пропускна здатність), і я думаю, що це цікавіше використовувати.

Оформити замовлення Git: http://git-scm.com/
Оформити замовлення викопного: http://www.fossil-scm.org
Оформити замовлення Mercurial: https://www.mercurial-scm.org

Зараз я можу рекомендувати лише системи DVC, і ви легко можете використовувати центральний сервер

Розподілені VCS приваблюють різними способами, але одним недоліком, який буде важливим для моєї компанії, є проблема управління файлами, що не об’єднуються (зазвичай це двійкові файли, наприклад, документи Excel). Subversion вирішує це, підтримуючи властивість "svn: needs-lock", що означає, що перед тим, як редагувати його, потрібно отримати блокування для файлу, що не підлягає об'єднанню. Це добре працює. Але для цього робочого процесу потрібна централізована модель сховища, що суперечить концепції DVCS.

Отже, якщо ви хочете використовувати DVCS, це насправді не підходить для управління файлами, які не об’єднуються.

Основною проблемою (окрім очевидної проблеми пропускної здатності) є власність .

Тобто переконайтеся, що різні (географічні) сайти не працюють над одним елементом, ніж інший.

В ідеалі інструмент може призначити право власності на файл, гілку або навіть сховище.

Щоб відповісти на коментарі до цієї відповіді, ви дійсно хочете, щоб інструмент повідомив, кому що належить, а потім спілкувався (за допомогою телефону, чату чи пошти) з віддаленим сайтом.
Якщо у вас немає механізму власності ... ви будете "спілкуватися", але часто занадто пізно;) (тобто: після одночасної розробки ідентичного набору файлів в одній гілці. Фіксація може бути брудною)

Для мене це чергова дискусія про особистий смак, і досить важко бути справді об'єктивним. Я особисто віддаю перевагу Mercurial перед іншими DVCS. Мені подобається писати хуки тією ж мовою, на якій написано Mercurial , і менші накладні витрати на мережу - просто сказати деякі мої власні причини.

У наші дні всі в курсі того, як DVCS перевершують, але коментар Крейга важливий. У DVCS кожна людина має всю історію філії. Якщо ви працюєте з великою кількістю двійкових файлів (наприклад, із файлами зображень або FLA), це вимагає величезної кількості місця, і ви не можете робити відмінності.

У мене відчуття, що Mercurial (та інші DVCS) є більш досконалими, ніж централізовані. Наприклад, злиття гілки в Mercurial зберігає повну історію гілки, тоді як у SVN вам потрібно перейти до каталогу гілки, щоб переглянути історію.

Ще одним плюсом для розподіленого SCM навіть у сценарії індивідуального розробника є те, що у вас, як і у багатьох з нас, є більше однієї машини, на якій ви працюєте.

Скажімо, у вас є набір загальних сценаріїв. Якщо кожна машина, на якій ви працюєте, має клон, ви можете на вимогу оновити та змінити свої сценарії. Це дає вам:

1. економія часу, особливо за допомогою клавіш ssh
2. спосіб розгалуження відмінностей між різними системами (наприклад, Red Hat проти Debian, BSD проти Linux тощо)

Відповідь В. Крейга Трейдера підсумовує більшу частину, проте, я вважаю, що особистий стиль роботи також має велике значення. Там, де я зараз працюю, ми використовуємо диверсію як наше єдине справжнє джерело, однак багато розробників використовують git-svn на своїх персональних машинах, щоб компенсувати проблему робочого процесу, яку ми маємо (невдача управління, але це вже інша історія). У будь-якому випадку. його справді стосується збалансування того, які набори функцій роблять вас найбільш продуктивним із тим, що потрібно організації (наприклад, централізована автентифікація).

Централізована система не обов'язково заважає вам використовувати окремі гілки для розвитку. Не потрібно мати єдиної справжньої копії бази коду, а різні розробники або команди можуть мати різні гілки, можуть існувати застарілі гілки тощо.

Загалом це означає, що сховищем управляється централізовано - але це, як правило, перевага у компанії з компетентним ІТ-відділом, оскільки це означає, що є лише одне місце для резервного копіювання та лише одне місце для управління сховищем.