Сравнение централизованных и распределенных систем управления версиями [закрыто]

Что такое преимущества и недостатки С помощью централизованные и распределенные системы контроля версий (DVCS)? Вы столкнулись с какими-либо проблемами в DVCS и как вы защитили от этих проблем? держите инструмент обсуждения агностическим и пылающим до минимума.

для тех, кто интересуется, какие инструменты DVCS доступны, вот список самых известных бесплатных / с открытым исходным кодом DVCSs:

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

15 ответов


с мой ответ: в другой вопрос:

распределенные системы контроля версий (DVCSs) разрешает различные проблемы чем Централизованный VCSs. Сравнивать их как сравнивать молоток и отвертки.

централизованный VCS системы разработанный с намерением, что есть Один истинный источник, Который благословен, и поэтому хорошо. Все разработчики работают (извлечение) из этого источника, а затем добавьте (зафиксируйте) свои изменения, которые затем стать благословлены. Единственный реальная разница между CVS, Subversion, ClearCase, Поневоле, VisualSourceSafe и все остальные CVCSes в процессе, производительность и интеграция, что каждый продуктовое предложение.

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

реальный выбор между использованием одного типа или другой-организационный ... ваш проект или организация хочет централизованное управление, тогда DVCS является без стартера. Если ваши разработчики ожидалось, что будет работать на всем протяжении страна / мир, без безопасности Широкополосное подключение к центральному репозиторий, затем DVCS вероятно, ваш спасение. Если вам нужны оба, ты для fsck бы.


для тех, кто думает, что распределенные системы не позволяют авторитетным копии обратите внимание, что есть много мест, где распространены системы имеют авторитетные копии, идеальный пример, вероятно Ядро дерева Лайнуса. Конечно, у многих людей есть свои деревья, но почти все они текут к дереву Лайнуса.

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

например, скажем, вы являетесь сольным разработчиком, работающим над своим личным проект. Централизованный репозиторий может быть очевидным выбором, но рассмотрим этот сценарий. Вы находитесь вдали от доступа к сети (на самолете, в парке и т. д.) и хотите работать над своим проектом. У вас есть свой местный скопируйте, чтобы вы могли работать нормально, но вы действительно хотите совершить, потому что вы закончили одну функцию и хотите перейти к другому, или вы нашли ошибка для исправления или что-то еще. Дело в том, что с централизованным РЕПО в конечном итоге вы либо смешиваете все изменения вместе и совершаете их в нелогичном наборе изменений или вы вручную разделите их позже.

с распределенным РЕПО вы продолжаете работать как обычно, фиксируете, двигаетесь дальше, когда у вас снова есть доступ к сети, вы нажимаете на свое "одно истинное РЕПО" и ничего не изменилось.

не говоря уже о другой приятной вещи о распределенные РЕПО: полный история доступна всегда. Вам нужно посмотреть журналы ревизий, когда от сети? Вам нужно аннотировать источник, чтобы увидеть, как ошибка был представлен? Все возможно с распределенными РЕПО.

пожалуйста, пожалуйста, не верьте, что распределенный vs централизованный о собственность, или авторитетные копии, или что-то в этом роде. Реальность распространяется является следующим шагом в эволюции SCM.


Не совсем сравнение, но вот какие большие проекты используют:

Централизованные VCSes

  • в Subversion

    Апач, ССЗ, Руби, и mplayer, синца, и Plone, стоит заметить, что форматом, FreeBSD, и в WebKit, ...

  • CVS

    CVS

распределенные VCSes

  • git

    ядра Linux в KDE, на Perl, Ruby на Rails, Андроид, вино, шляпа, X.org, Медиавики, Джанго звука, моно, Гном, Самба, чашки, при помощи GnuPG, то Emacs ЭЛПА...

  • ртутный (hg)

    Mozilla и Моздев, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Голубятня, MoinMoin, mutt, PETSc, Октава, Феникс, Aptitude, Python, XEmacs, Xen, Vim, Ксин...

  • bzr

    Emacs, Apt, Почтальон, MySQL, Squid, ... также продвигается в Ubuntu.

  • помощью darcs

    ghc, ion, xmonad,... популярный в сообществе Haskell.

  • ископаемых

    SQLite


У. Крейг Трейдера сказал Это О DVCS и CVCS:

Если вам нужны оба, ты бы для fsck.

Я бы не сказал, что ты для fsck, что при использовании обоих. Практически разработчики, которые используют инструменты DVCS, обычно пытаются объединить свои изменения (или отправить запросы pull) против центрального местоположения (обычно в ветку выпуска в репозитории выпуска). Есть некоторая ирония с разработчиками, которые используют DVCS, но в конце концов придерживаются централизованного рабочий процесс, вы можете начать задаваться вопросом, Действительно ли распределенный подход лучше, чем централизованный.

есть некоторые преимущества с DVCS над CVCS:

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

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

  • в современном мире компании обычно работают с оффшорными разработчиками (или, если даже лучше, они хотят работать с домашний.) Наличие DVCS помогает таким проектам, потому что устраняет необходимость надежного сетевого подключения, поскольку у каждого есть свое собственное РЕПО.

...и некоторые недостатки, которые обычно имеют обходные пути:

  • у кого последняя редакция? в CVCS магистраль обычно имеет последнюю версию,но в DVCS это может быть не очевидно. Обходным путем является использование правил поведения, которые разработчики в проекте должны прийти к соглашению, в котором РЕПО объединить свою работу против.

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

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


во время поиска правильного SCM я нашел следующие ссылки, которые очень помогли:

  1. Лучшая инициатива SCM: сравнение. Сравнение около 26 систем контроля версий.
  2. сравнение программного обеспечения управления ревизией. Статья Википедии, сравнивающая около 38 систем управления версиями, охватывающих такие темы, как технические различия, функции, пользовательские интерфейсы и многое другое.
  3. распределенные системы контроля версий системы. Еще одно сравнение, но сосредоточенное в основном на распределенных системах.

в некоторой степени две схемы эквивалентны:

  • распределенные VCS могут тривиально эмулировать централизованный, если вы просто всегда нажимаете свои изменения на какой-то назначенный восходящий репозиторий после каждой локальной фиксации.
  • централизованный VCS обычно не сможет эмулировать распределенный так же естественно, но вы можете получить что-то очень похожее, если вы используете что-то вроде одеяло поверх него. Одеяло, Если вы не знакомы с ним, - это инструмент для управления большими наборами патчей поверх проекта. Идея здесь заключается в том, что команда DVCS commit реализуется путем создания нового патча, а команда push реализуется путем фиксации каждого выдающегося патча к централизованным VCS, а затем отбрасывания файлов патча. Это звучит немного неловко, но на практике это работает довольно хорошо.

сказав это, есть несколько вещей, которые DVCSes традиционно делают очень хорошо, и которые большинство централизованные VCSes делают немного хэша. Наиболее важным из них, вероятно, является ветвление: DVCS позволит очень легко ветвить репозиторий или объединить ветви, которые больше не нужны, и будет отслеживать историю во время этого. Нет никаких особых причин, почему централизованная схема будет иметь проблемы с этим, но исторически никто, кажется, еще не получил его правильно. Действительно ли это проблема для вас, зависит от того, как вы собираетесь организовать развитие, но для многих людей это важное соображение.

другим положенным преимуществом DVCSes является то, что они работают в автономном режиме. Я никогда не использовал это; я в основном занимаюсь разработкой либо в офисе (поэтому репозиторий находится в локальной сети), либо дома (так что есть ADSL). Если вы делаете много разработки на ноутбуках во время путешествия, то это может быть более важным для вас.

на самом деле не так много gotchas, которые специфичны для DVCSes. Есть немного больше склонности к тому, чтобы люди молчали, потому что вы можете совершить, не подталкивая, и легко закончить полировку вещей в частном порядке, но кроме этого у нас не было очень много проблем. Это может быть связано с тем, что у нас есть значительное количество разработчиков с открытым исходным кодом, которые обычно знакомы с патч-трейдинговой моделью разработки, но входящие разработчики с закрытым исходным кодом также, похоже, достаточно быстро подбирают вещи.


распределенные VCS привлекательны во многих отношениях, но один недостаток, который будет важен для моей компании,-это проблема управления не объединяемыми файлами (обычно двоичными, например, документами Excel). Subversion занимается этим, поддерживая свойство" svn:needs-lock", что означает, что вы должны получить блокировку для файла без слияния перед его редактированием. Это хорошо работает. Но этот рабочий поток требует централизованной модели репозитория, что противоречит концепции DVCS.

Итак, если вы хотите используйте DVCS, это не очень подходит для управления файлами, которые не могут быть объединены.


Я использую subversion уже много лет, и я был очень доволен этим.

затем началось гудение GIT, и мне просто нужно было проверить его. И для меня главным пунктом продажи было разветвление. О боже. Теперь мне больше не нужно очищать репозиторий, возвращаться к нескольким версиям или любым глупостям, которые я делал при использовании subversion. В dvcs все дешево. Я только пробовал fossil и git, но я использовал perforce, cvs и subversion, и похоже, что все dvcs действительно дешевое ветвление и маркировка. Больше не нужно копировать весь код в одну сторону, и поэтому слияние-это просто мелочь.

любой dvcs может быть настроен с центральным сервером, но то, что вы получаете, среди прочего

вы можете проверить любое небольшое изменение, которое вам нравится, как говорит Лайнус, если вам нужно использовать более одного предложения для описания того, что вы только что сделали, вы делаете слишком много. Вы можете иметь свой путь с кодом, ветвью, слиянием, клонированием и тестированием все локально, не вызывая никого скачать огромное количество данных. И Вам только нужно нажать окончательные изменения в центральный сервер.

и вы можете работать без сети.

короче говоря, использование контроля версий всегда хорошо. Использование dvcs дешевле (в КБ и пропускной способности), и я думаю, что это более интересно использовать.

для проверки Git:http://git-scm.com/
Чтобы проверить ископаемое:http://www.fossil-scm.org
Проверка ртутный : https://www.mercurial-scm.org

теперь я могу рекомендовать только системы dvcs, и вы легко можете использовать центральный сервер


основная проблема (помимо очевидной проблемы с пропускной способностью) -собственности.

Это, чтобы быть уверенным, что другой (географический) сайт не работает над тем же элементом, что и другой.

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

чтобы ответить на комментарии этого ответа, вы действительно хотите, чтобы инструмент, чтобы сказать вам, кто чем владеет, и затем общайтесь (через телефон, IM или почту) с отдаленного участка.
Если у вас нет механизма ответственности... вы будете "общаться", но часто слишком поздно ;) (т. е.: после одновременной разработки идентичного набора файлов в одной ветке. Фиксация может стать грязной)


для меня это еще одна дискуссия о личном вкусе, и довольно сложно быть действительно объективным. Лично я предпочитаю Mercurial над другими DVCS. Мне нравится писать крючки на том же языке, что и Mercurial записывается и меньшие сетевые накладные расходы - просто сказать некоторые из моих собственных причин.


все в эти дни на подножке о том, как DVCSs превосходят, но комментарий Крейга важен. В DVCS каждый человек имеет всю историю филиала. Если вы работаете с большим количеством двоичных файлов (например, файлов изображений или FLAs), это требует огромного пространства, и вы не можете делать различия.


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


еще один плюс для распределенного SCM даже в сценарии solo developer-если у вас, как и у многих из нас, есть более одной машины, на которой вы работаете.

допустим, у вас есть набор стандартных скриптов. Если каждая машина, на которой вы работаете, имеет клон, вы можете по требованию обновить и изменить свои сценарии. Это дает вам:

  1. экономия времени, особенно с SSH-ключами
  2. способ разделения различий между различными системами (например, Red Hat vs Debian, BSD vs Linux, и т. д.)

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


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

обычно это означает, что репозиторий управляется централизованно , но это, как правило, преимущество в компании с компетентным ИТ-отделом, потому что это означает, что есть только одно место для резервного копирования и только одно место для управления хранилищем.