it-swarm.com.ru

Сравнение между централизованной и распределенной системами контроля версий

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

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

76
Spoike

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

Распределенные системы контроля версий (DVCS) решают проблемы, отличные от централизованных VCS. Сравнивать их - все равно что сравнивать молотки и отвертки.

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

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

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

56
Craig Trader

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

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

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

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

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

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

46
manicmethod

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

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

  • Subversion

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

  • CVS

    CVS

Распределенные VCS

  • мерзавец

    Ядро Linux, KDE, Perl, Ruby на Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...

  • Mercurial (hg)

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

  • FAE

    Emacs, Apt, Mailman, MySQL, Squid, ... также продвигаются в Ubuntu.

  • Darcs

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

  • Fossil

    SQLite

25
sastanin

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

Если вам нужны оба, вы fsck'd.

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

Есть несколько преимуществ с DVCS по сравнению с CVCS:

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

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

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

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

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

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

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

20
Spoike

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

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

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

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

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

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

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

8
Steven Smith

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

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

4
Craig McQueen

Я использую Subversion уже много лет, и мне это очень понравилось.

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

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

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

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

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

Чтобы оформить заказ Git: http://git-scm.com/
Чтобы оформить заказ Fossil: http://www.Fossil-scm.org
Чтобы оформить заказ Mercurial: https://www.Mercurial-scm.org

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

4
Trausti Thor

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

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

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

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

3
VonC

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

3
unexist

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

2
elmonty

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

1
Roman Plášil

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

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

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

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

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

0
MarkR

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

0
Mark Kegel