Каковы относительные сильные и слабые стороны Git, Mercurial и Bazaar?[закрыто]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Что, по мнению присутствующих здесь людей, является относительными сильными и слабыми сторонами Git, Mercurial и Bazaar?
Рассматривая каждый из них друг с другом и в сравнении с системами контроля версий, такими как SVN и Perforce, какие вопросы следует учитывать?
Планируя переход с SVN на одну из этих распределенных систем контроля версий, какие факторы вы бы приняли во внимание?
Решение
Git очень быстр, очень хорошо масштабируется и очень прозрачен в отношении своих концепций.Недостатком этого является то, что он имеет относительно крутую кривую обучения.Порт Win32 доступен, но не совсем для первоклассного пользователя.Git предоставляет пользователям хэши в виде номеров версий;это обеспечивает гарантии (в том смысле, что один хэш всегда ссылается на одно и то же содержимое;злоумышленник не может изменить историю незамеченным), но может быть обременительным для пользователя.Git обладает уникальной концепцией отслеживания содержимого файлов, даже когда это содержимое перемещается между файлами, и рассматривает файлы как объекты первого уровня, но не отслеживает каталоги.Другая проблема с git заключается в том, что он содержит много операций (таких как перебазирование), которые упрощают изменение истории (в некотором смысле - содержимое, на которое ссылается хэш, никогда не изменится, но ссылки на этот хэш могут быть потеряны);некоторым пуристам (включая меня) это не очень нравится.
Bazaar работает достаточно быстро (очень быстро для деревьев с неглубокой историей, но в настоящее время плохо масштабируется в зависимости от длины истории) и прост в освоении для тех, кто знаком с интерфейсами командной строки традиционных SCM (CVS, SVN и т.д.).Команда разработчиков считает Win32 первоклассной целевой программой.Он имеет подключаемую архитектуру для различных компонентов и часто заменяет формат хранения;это позволяет им внедрять новые функции (такие как улучшенная поддержка интеграции с системами контроля версий, основанными на различных концепциях) и повышать производительность.Команда Bazaar считает, что отслеживание каталогов и поддержка переименования являются первоклассной функциональностью.В то время как глобально уникальные идентификаторы ревизий доступны для всех ревизий, локальные по дереву revnos (стандартные номера ревизий, более похожие на те, которые используются svn или другими более традиционными SCMS) используются вместо хэшей содержимого для идентификации ревизий.Bazaar поддерживает "облегченные проверки", при которых история хранится на удаленном сервере, а не копируется в локальную систему, и при необходимости к ней автоматически обращаются по сети;в настоящее время это не имеет аналогов среди DSCMS.
Оба имеют доступную ту или иную форму интеграции с SVN;однако bzr-svn значительно более эффективен, чем git-svn, в основном из-за изменений формата бэкэнда, введенных для этой цели. [Обновление, по состоянию на 2014 год:Сторонний коммерческий продукт SubGit предоставляет двунаправленный интерфейс между SVN и Git, который сравним по точности с bzr-svn и значительно более отточен;Я сильно рекомендую использовать его вместо git-svn, когда позволяют бюджетные и лицензионные ограничения].
Я не использовал Mercurial широко и поэтому не могу комментировать его подробно - за исключением того, что он, как и Git, имеет адресацию content-hash для ревизий;также, как и Git, он не рассматривает каталоги как объекты первого класса (и не может хранить пустой каталог).Однако он быстрее любого другого DSCM, за исключением Git, и имеет гораздо лучшую интеграцию с IDE (особенно для Eclipse), чем любой из его конкурентов.Учитывая его характеристики производительности (которые лишь незначительно отстают от характеристик Git) и превосходную кроссплатформенность и поддержку IDE, Mercurial может быть привлекателен для команд со значительным числом участников, ориентированных на win32 или IDE.
Одна из проблем при переходе с SVN заключается в том, что интерфейсы SVN с графическим интерфейсом и интеграция с IDE являются более зрелыми, чем у любой из распределенных SCM.Кроме того, если вы в настоящее время активно используете предварительную автоматизацию скриптов с помощью SVN (ie.требующий прохождения модульных тестов перед выполнением коммита), вы, вероятно, захотите использовать инструмент, подобный PQM для автоматизации запросов на слияние с вашими общими филиалами.
SVK - это DSCM, который использует Subversion в качестве резервного хранилища и имеет довольно хорошую интеграцию с инструментами, ориентированными на SVN.Однако он обладает значительно худшими характеристиками производительности и масштабируемости, чем любой другой крупный DSCM (даже Darcs), и его следует избегать для проектов, которые могут стать большими с точки зрения либо продолжительности истории, либо количества файлов.
[Об авторе:Я использую Git и Perforce для работы, а также Bazaar для своих личных проектов и в качестве встроенной библиотеки;другие подразделения организации моего работодателя активно используют Mercurial.В прошлой жизни я построил большую часть автоматизации вокруг SVN;до этого у меня был опыт работы с GNU Arch, BitKeeper, CVS и другими.Сначала Git был довольно отталкивающим - он казался похожим на GNU Arch, поскольку был концептуальной средой, в отличие от наборов инструментов, созданных в соответствии с выбором рабочих процессов пользователем, - но с тех пор я стал вполне доволен им].
Другие советы
Стив Стритинг из проекта Ogre 3D только что (28.09.2009) опубликовал запись в блоге на эту тему, где он делает отличную и беспристрастную работу. сравнение Git, Mercurial и Bazaar.
В конце концов, он находит сильные и слабые стороны у всех троих и не находит явного победителя.С другой стороны, он предлагает отличную таблицу, которая поможет вам решить, с какой из них выбрать.
Это краткое чтение, и я настоятельно рекомендую его.
Что, по мнению присутствующих здесь людей, является относительными сильными и слабыми сторонами Git, Mercurial и Bazaar?
На мой взгляд Мерзавец сила заключается в его чистом базовом дизайне и очень богатом наборе функций.Я также считаю, что он обладает наилучшей поддержкой для многоотраслевых репозиториев и управления рабочими процессами с большим объемом работы.Он очень быстрый и имеет небольшой размер хранилища.
В нем есть некоторые полезные функции, но для того, чтобы привыкнуть к ним, требуются определенные усилия.К ним относятся видимый промежуточный промежуточный ara (индекс) между рабочей областью и базой данных репозитория, который обеспечивает лучшее разрешение слияния в более сложных случаях, инкрементное объединение и объединение с грязным деревом; обнаружение переименовывает и копирует, используя эвристику подобия, а не отслеживает их, используя какие-то идентификаторы файлов, которые хорошо работают и которые позволяют обвинять (аннотировать), которые могут отслеживать перемещение кода по файлам, а не только массовые переименования.
Одним из его недостатков является то, что поддержка MS Windows отстает и не является полной.Другим воспринимаемым недостатком является то, что он не так хорошо документирован, как, например, Mercurial, и менее удобен для пользователя, чем конкуренты, но он меняется.
На мой взгляд Переменчивый сила заключается в его хорошей производительности и небольшом размере репозитория, а также в хорошей поддержке MS Windows.
Основным недостатком, на мой взгляд, является тот факт, что локальные ветви (несколько ветвей в одном репозитории) по-прежнему являются гражданами второго сорта и странным и сложным образом реализуют теги.Кроме того, способ, которым он обрабатывает переименования файлов, был неоптимальным (но этот момент изменился).Mercurial не поддерживает слияния octopus (с более чем двумя родителями).
Из того, что я услышал и прочитал, главное Базар преимуществами являются простая поддержка централизованного рабочего процесса (что также является недостатком, поскольку централизованные концепции видны там, где этого не должно быть), отслеживание переименований как файлов, так и каталогов.
Его основными недостатками являются производительность и размер репозитория для больших репозиториев с длинной нелинейной историей (производительность улучшилась, по крайней мере, для не слишком больших репозиториев), тот факт, что парадигмой по умолчанию является одно ранчо на репозиторий (впрочем, вы можете настроить его для совместного использования данных), и централизованные концепции (но это также, как я слышал, меняется).
Git написан на C, shell-скриптах и Perl и доступен для написания сценариев;Mercurial написан на C (core, для повышения производительности) и Python и предоставляет API для расширений;Bazaar написан на 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 и списках рассылки, а также сообщений в блогах и статей, сравнивающих различные системы контроля версий (некоторые из которых перечислены на Сравнение GIT страница в Git Wiki).
Информация имеет хорошее сравнение.
Mercurial и Bazaar внешне очень похожи друг на друга.Они оба обеспечивают базовый распределенный контроль версий, как при автономной фиксации, так и при объединении нескольких ветвей, оба написаны на python и оба работают медленнее, чем git.Когда вы вникаете в код, становится ясно много различий, но для ваших рутинных повседневных задач они фактически одинаковы, хотя Mercurial, кажется, обладает немного большей динамичностью.
Git, ну, это не для непосвященных.Он намного быстрее, чем Mercurial и Bazaar, и был написан для управления ядром Linux.Это самый быстрый из трех, а также самый мощный из трех, с большим отрывом.Инструменты Git для работы с журналами и фиксацией не имеют себе равных.Однако он также является самым сложным и опасным в использовании.Очень легко потерять коммит или испортить репозиторий, особенно если вы не понимаете внутреннюю работу git.
Взгляните на сравнение, сделанное недавно разработчиками Python: http://wiki .python.org/moin/DvcsComparison.Они выбрали Mercurial по трем важным причинам:
Выбор в пользу Mercurial был сделан по трем важным причинам:
- Согласно небольшому опросу, разработчики Python больше заинтересованы в использовании Mercurial , чем в Bazaar или Git.
- Mercurial написан на Python, что соответствует тенденции разработчиков python "есть свой собственный корм для собак".
- Mercurial работает значительно быстрее, чем bzr (он медленнее, чем git, хотя и с гораздо меньшей разницей).
- Пользователям SVN Mercurial легче освоить, чем Bazaar.
Sun провела оценку мерзавец, Переменчивый, и Базар в качестве кандидатов на замену Sun Teamware VCS для кодовой базы Solaris.Мне это показалось очень интересным.
Некоторое время я пользовался Bazaar, который мне очень нравился, но это были только небольшие проекты, и даже тогда он был довольно медленным.Так легко учиться, но не очень быстро.Тем не менее, это очень x-платформа.
В настоящее время я использую Git, который мне очень нравится, поскольку версия 1.6 сделала его намного более похожим на другие виртуальные машины с точки зрения используемых команд.
Я думаю, что основные отличия моего опыта использования DVCS заключаются в следующем:
- У Git самое динамичное сообщество, и часто можно увидеть статьи о Git
- ГитХаб действительно потрясающе.Launchpad.net - это нормально, но ничто не сравнится с удовольствием от Github
- Количество инструментов рабочего процесса для Git было огромным.Он интегрирован повсюду.Есть некоторые для Bzr, но их и близко не так много и они не в таком хорошем состоянии.
Подводя итог, можно сказать, что Bzr был великолепен, когда я стригся на DVCS, но сейчас я очень доволен Git и Github.
Это большой вопрос, который во многом зависит от контекста, и вам потребуется много времени, чтобы ввести его в одно из этих маленьких текстовых полей.Кроме того, все три из них кажутся существенно похожими, когда используются для обычных задач, которыми занимается большинство программистов, так что даже понимание различий требует некоторых довольно эзотерических знаний.
Вероятно, вы получите гораздо лучшие ответы, если сможете разбить свой анализ этих инструментов до того момента, когда у вас возникнут более конкретные вопросы.
Bazaar, ИМХО, легче освоить, чем git.Git имеет хорошую поддержку в github.com.
Я думаю, вам следует попробовать использовать и то, и другое и решить, что подходит вам больше всего.
Что, по мнению присутствующих здесь людей, является относительными сильными и слабыми сторонами Git, Mercurial и Bazaar?
Это очень открытый вопрос, граничащий с блесной.
Git самый быстрый, но все три достаточно быстры.Bazaar является наиболее гибким (он имеет прозрачную поддержку чтения-записи для репозиториев SVN) и очень заботится об удобстве работы пользователя.Mercurial находится где-то посередине.
У всех трех систем много поклонников.Лично я фанат Bazaar.
Рассматривая каждый из них друг с другом и в сравнении с системами контроля версий, такими как SVN и Perforce, какие вопросы следует учитывать?
Первые представляют собой распределенные системы.Последние представляют собой централизованные системы.Кроме того, Perforce является собственностью, в то время как все остальные являются бесплатными как в речи.
Централизованный или децентрализованный выбор - гораздо более важный выбор, чем любая из систем, которые вы упомянули в своей категории.
Планируя переход с SVN на одну из этих распределенных систем контроля версий, какие факторы вы бы приняли во внимание?
Во-первых, отсутствие хорошей замены TortoiseSVN.Хотя Bazaar работает самостоятельно Вариант с черепахой, но по состоянию на сентябрь 2008 года его там еще нет.
Затем обучите ключевых сотрудников тому, как использование децентрализованной системы повлияет на их работу.
Наконец, интеграция с остальной частью системы, такой как средства отслеживания проблем, система ночной сборки, автоматизированная тестовая система и т.д.
Ваша главная проблема будет заключаться в том, что это Распределенный SCMS и как таковые требуют небольшого изменения мышления пользователя.Как только люди привыкнут к этой идее, технические детали и схемы использования встанут на свои места, но не стоит недооценивать это первоначальное препятствие, особенно в корпоративной среде.Помните, что все проблемы - это проблемы людей.
ddaa.myopenid.com упоминал об этом вскользь, но я думаю, об этом стоит упомянуть еще раз:Bazaar может читать и записывать данные в удаленные репозитории SVN.Это означает, что вы могли бы использовать Bazaar локально в качестве проверки концепции, в то время как остальная часть команды все еще использует Subversion.
Редактировать:Практически весь инструмент, который сейчас есть некоторые способ взаимодействия с SVN, но теперь у меня есть личный опыт, который git svn работает чрезвычайно что ж.Я пользуюсь им уже несколько месяцев, с минимальными сбоями.
На git есть хорошее видео Линуса Торвальдса.Он является создателем Git, так что это то, что он продвигает, но в видео он объясняет, что такое распределенные SCM и почему они лучше централизованных.Существует множество сравнений git (mercurial считается приемлемым) и cvs / svn / perforce.Также есть вопросы от аудитории относительно перехода на распределенную SCM.
Я нашел этот материал поучительным, и я продан компании distributed SCM.Но, несмотря на усилия Лайнуса, мой выбор непостоянен.Причина в том, bitbucket.org что я нашел его лучше (более щедрым), чем github.
Я должен сказать здесь одно предупреждение:У Лайнуса довольно агрессивный стиль, я думаю, он хочет быть смешным, но я не смеялся.Кроме того, видео будет отличным, если вы новичок в распределенных SCMS и подумываете о переходе с SVN.
Распределенные системы контроля версий (DVCSS) решают иные задачи, чем централизованные VCS.Сравнивать их - все равно что сравнивать молотки и отвертки.
Централизованные венчурные капиталисты системы разрабатываются с намерением, чтобы существовал Один Истинный Источник, который Благословен и, следовательно, Хорош.Все разработчики работают (оформляют заказ) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся такими же благословенными.Единственное реальное различие между CVS, Subversion, ClearCase, Perforce, VisualSourceSafe и всеми другими CVCS заключается в рабочем процессе, производительности и интеграции, которые предлагает каждый продукт.
Распределенные венчурные капиталисты системы разрабатываются с намерением, чтобы один репозиторий был так же хорош, как и любой другой, и чтобы слияния из одного репозитория в другой были просто еще одной формой коммуникации.Любое семантическое значение относительно того, какому репозиторию следует доверять, навязывается извне процессом, а не самим программным обеспечением.
Реальный выбор между использованием того или иного типа зависит от организации - если вашему проекту или организации требуется централизованное управление, то DVCS - это не первый вариант.Если ожидается, что ваши разработчики будут работать по всей стране / миру без безопасных широкополосных подключений к центральному хранилищу, то DVCS, вероятно, станет вашим спасением.Если вам нужно и то, и другое, вы fsck'd.
