it-swarm-ru.tech

Каковы относительные сильные и слабые стороны Git, Mercurial и Bazaar?

Что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?

Какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как SVN и Perforce?

При планировании перехода от SVN к одной из этих распределенных систем контроля версий, какие факторы вы бы учитывали?

135
Jordan Dea-Mattson

Git очень быстр, очень хорошо масштабируется и очень прозрачен в своих концепциях. Недостатком этого является то, что у него относительно крутая кривая обучения. Порт Win32 доступен, но не совсем первоклассный гражданин. Git выставляет хэши как номера версий пользователям; это обеспечивает гарантии (в том смысле, что один хэш всегда ссылается на одно и то же содержимое; злоумышленник не может изменить историю, не будучи обнаруженным), но может быть громоздким для пользователя. Git имеет уникальную концепцию отслеживания содержимого файла, даже если это содержимое перемещается между файлами и просматривает файлы как объекты первого уровня, но не отслеживает каталоги. Другая проблема с git - это много операций (таких как перебазировать) которые позволяют легко изменять историю (в некотором смысле - содержимое, на которое ссылается хеш, никогда не изменится, но ссылки на этот хэш могут быть потеряны); некоторым пуристам (включая меня) это не очень нравится.

Базар достаточно быстрый (очень быстрый для деревьев с мелкой историей, но в настоящее время плохо масштабируется с длиной истории) и прост в освоении тем, кто знаком с интерфейсами командной строки традиционных SCM (CVS, SVN и т.д.). Win32 считается первоклассной целью его команды разработчиков. Он имеет подключаемую архитектуру для различных компонентов и часто заменяет свой формат хранения; это позволяет им внедрять новые функции (например, улучшенную поддержку интеграции с системами контроля версий на основе различных концепций) и повышать производительность. Команда Bazaar рассматривает отслеживание каталогов и поддержку переименования первоклассными функциями. Хотя глобально уникальные идентификаторы идентификаторов ревизий доступны для всех ревизий, вместо хеш-содержимого контента для идентификации ревизий используются локальные древовидные ревно (стандартные номера ревизий, более схожие с теми, которые используются svn или другими более традиционными SCM). Bazaar поддерживает "облегченные проверки", в которых история хранится на удаленном сервере, а не копируется в локальную систему, и при необходимости автоматически передается по сети; в настоящее время это уникально среди DSCM.

Оба имеют некоторую форму интеграции SVN; тем не менее, bzr-svn значительно более эффективен, чем git-svn, в основном из-за изменений в формате внутреннего интерфейса, введенных для этой цели. [Обновление от 2014 года: сторонний коммерческий продукт SubGit обеспечивает двунаправленный интерфейс между SVN и Git, сравнимый по точности с bzr-svn и значительно улучшенный; я сильно рекомендовать его использование вместо git-svn, когда позволяют бюджетные и лицензионные ограничения].

Я не использовал Mercurial широко, и поэтому не могу комментировать его подробно - кроме как отметить, что он, как и Git, имеет хеш-контент-адресацию для ревизий; также как и Git, он не рассматривает каталоги как первоклассные объекты (и не может хранить пустой каталог). Однако он работает быстрее, чем любой другой DSCM, за исключением Git, и имеет намного лучшую интеграцию IDE (особенно для Eclipse), чем любой из его конкурентов. Учитывая его характеристики производительности (которые немного отстают от Git), а также превосходную кроссплатформенность и поддержку IDE, Mercurial может быть привлекательным для команд со значительным количеством win32-ориентированных или связанных с IDE участников.

Одна из проблем при переходе с SVN заключается в том, что внешние интерфейсы GUI SVN и интеграция IDE более развиты, чем у любого из распределенных SCM. Кроме того, если вы в настоящее время интенсивно используете автоматизацию сценариев предварительной фиксации с SVN (т. Е. Требовать прохождения модульных тестов, прежде чем можно будет продолжить фиксацию), вы, вероятно, захотите использовать инструмент, аналогичный PQM для автоматизации запросов на слияние ваших общих веток.

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

[Об авторе: я использую Git и Perforce для работы и Bazaar для своих личных проектов и в качестве встроенной библиотеки; другие части организации моего работодателя активно используют Mercurial. В прошлой жизни я построил большую автоматизацию вокруг SVN; до этого у меня был опыт работы с GNU Arch, BitKeeper, CVS и другими. Поначалу Git был довольно унылым - он чувствовал себя как GNU Arch, поскольку он является концептуально сложной средой, в отличие от наборов инструментов, созданных в соответствии с выбором рабочих процессов пользователя - но с тех пор я чтобы быть вполне комфортно с этим].

142
Charles Duffy

Стив Стрингинг из проекта Ogre 3D (28.09.2009) опубликовал запись в блоге на эту тему, где он отлично справляется и даже вручает сравнение Git, Mercurial и Bazaar .

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

alt text

Это краткое чтение, и я очень рекомендую его.

19
Michael La Voie

Что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?

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

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

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

На мой взгляд Сила Mercurial заключается в его хорошей производительности и небольшом размере репозитория, в его хорошей поддержке MS Windows.

Основным недостатком, на мой взгляд, является тот факт, что локальные ветви (несколько ветвей в одном репозитории) по-прежнему являются гражданами второго сорта и странным и сложным образом реализуют теги. Также способ, которым это имеет дело с переименованиями файлов, был неоптимальным (но это изменение изменилось) Mercurial не поддерживает слияния осьминогов (с более чем двумя родителями).

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

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

Git написан на C, сценариях Shell и Perl, и является сценарием; Mercurial написан на C (ядро, для производительности) и Python и предоставляет API для расширений; Базар написан на Python и предоставляет API для расширений.


Какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как SVN и Perforce?

Системы контроля версий, такие как Subversion (SVN), Perforce или ClearCase, являются централизованными системами контроля версий. Git, Mercurial, Bazaar (а также Darcs, Monotone и BitKeeper) являются распределенными системами контроля версий. Распределенные системы контроля версий обеспечивают гораздо более широкий диапазон рабочих процессов. Они позволяют использовать "публиковать, когда готовы". У них улучшена поддержка ветвления и слияния, а также рабочих процессов с интенсивным ветвлением. Вам не нужно доверять людям с доступом к коммитам, чтобы иметь возможность получать вклады от них простым способом.


При планировании перехода с SVN на одну из этих распределенных систем контроля версий, какие факторы вы бы учитывали?

Одним из факторов, который вы можете рассмотреть, является поддержка невмешательства в SVN; У Git есть git-svn, у Bazaar есть bzr-svn, а у Mercurial есть расширение hgsubversion.

Отказ от ответственности: Я являюсь пользователем Git и небольшим участником, и наблюдаю (и участвую) в списке рассылки git. Я знаю Mercurial и Bazaar только по их документации, различным обсуждениям IRC и ​​спискам рассылки, а также публикациям в блогах и статьям, сравнивающим различные системы контроля версий (некоторые из которых перечислены на странице GitComparison на Git Wiki).

15
Jakub Narębski
14
Pat Notz

Mercurial и Bazaar очень похожи на поверхности. Они оба обеспечивают базовое управление распределенной версией, как при автономной фиксации и слиянии нескольких ветвей, так и написаны в python и ​​работают медленнее, чем git. Когда вы углубляетесь в код, есть много различий, но для ваших повседневных задач они практически одинаковы, хотя, похоже, Mercurial обладает немного большей динамикой.

Git, ну, не для непосвященных. Он намного быстрее, чем Mercurial и Bazaar, и был написан для управления ядром Linux. Это самый быстрый из трех, и это также самый мощный из трех, с большим отрывом. Средства управления журналом и фиксацией в Git не имеют себе равных. Тем не менее, это также самый сложный и самый опасный в использовании. Очень легко потерять коммит или испортить репозиторий, особенно если вы не понимаете внутреннюю работу git.

7
Herge

Посмотрите на сравнение, сделанное недавно разработчиками Python: http://wiki.python.org/moin/DvcsComparison . Они выбрали Mercurial по трем важным причинам:

Выбор Mercurial был сделан по трем важным причинам:

  • Согласно небольшому опросу, Python разработчики больше заинтересованы в использовании Mercurial, чем в Bazaar или Git.
  • Mercurial написан на Python, что согласуется с тенденцией python-dev "есть свою собачью еду".
  • Mercurial значительно быстрее, чем bzr (он медленнее, чем git, хотя и с гораздо меньшей разницей).
  • Mercurial проще для пользователей SVN, чем Bazaar.

(из http://www.python.org/dev/peps/pep-0374/ )

6
Martin Geisler

Sun провела оценку git , Mercurial и Bazaar в качестве кандидатов на замену Sun Teamware VCS для базы кода Solaris. Я нашел это очень интересным.

5
DGentry

Очень важная пропущенная вещь на базаре - cp. Вы не можете иметь несколько файлов с одинаковой историей, как в SVN, см., Например, здесь и здесь . Если вы не планируете использовать cp, bzr - отличная (и очень простая в использовании) замена svn.

2
Davide

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

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

Я думаю, что основные различия в моем опыте использования DVCS заключаются в следующем:

  1. У Git самое оживленное сообщество, и часто можно увидеть статьи о Git
  2. GitHub действительно качается. Launchpad.net в порядке, но ничего подобного удовольствию от Github
  3. Количество инструментов рабочего процесса для Git было огромным. Это интегрировано повсеместно. Есть некоторые для Bzr, но не так много или в хорошем состоянии.

Таким образом, Bzr был великолепен, когда я резал зубы на DVCS, но теперь я очень доволен Git и Github.

2
sh1mmer

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

1
David Plumpton

Базар ИМХО легче учить, чем мерзавец. Git имеет хорошую поддержку на github.com.

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

1
Rafał Rawicki

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

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

1
jfm3

Что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?

Это очень открытый вопрос, граничащий с приманкой.

Git самый быстрый, но все три достаточно быстрые. Базар является наиболее гибким (имеет прозрачную поддержку чтения и записи для SVN-репозиториев) и очень заботится о взаимодействии с пользователем. Mercurial где-то посередине.

Все три системы имеют множество фанатов. Я лично фанат Bazaar.

Какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как SVN и Perforce?

Первые являются распределенными системами. Последние являются централизованными системами. Кроме того, Perforce является частной собственностью, а все остальные бесплатны как в речи .

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

При планировании перехода от SVN к одной из этих распределенных систем контроля версий, какие факторы вы бы учитывали?

Во-первых, отсутствие хорошей замены TortoiseSVN. Хотя Bazaar работает самостоятельно вариант с черепахой , но его еще нет, по состоянию на сентябрь 2008 года.

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

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

1
ddaa

ddaa.myopenid.com упомянул об этом попутно, но я думаю, что стоит упомянуть еще раз: Bazaar может читать и писать в удаленные репозитории SVN. Это означает, что вы можете использовать Bazaar локально в качестве подтверждения концепции, в то время как остальная часть команды все еще использует Subversion.

Правка: Практически все инструменты теперь имеют некоторый способ взаимодействия с SVN, но теперь у меня есть личный опыт работы git svnчрезвычайно = хорошо Я использовал его в течение нескольких месяцев, с минимальными отклонениями.

1
Hank Gay

На Git есть хорошее видео Линуса Торвальдса. Он является создателем Git, так что это то, что он продвигает, но в видео он объясняет, что такое распределенные SCM и почему они лучше, чем централизованные. Существует много сравнений между git (Mercurial считается нормальным) и cvs/svn/Perforce. Есть также вопросы от аудитории относительно перехода на распределенную SCM.

Я нашел этот материал поучительным, и я продан распределенному СКМ. Но, несмотря на усилия Линуса, мой выбор - Mercurial. Причина в bitbucket.org, я нашел его лучше (более щедрым), чем github.

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

http://www.youtube.com/watch?v=4XpnKHJAok8

1
k1udge

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

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

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

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

0
Craig Trader