В чем здесь люди видят относительные сильные и слабые стороны Git, Mercurial и Bazaar?
Какие проблемы следует учитывать при рассмотрении каждого из них друг с другом и с системами контроля версий, такими как SVN и Perforce?
Какие факторы вы бы приняли во внимание при планировании перехода с SVN на одну из этих распределенных систем контроля версий?
Ответы:
Git очень быстр, хорошо масштабируется и очень прозрачен в своих концепциях. Обратной стороной является относительно крутая кривая обучения. Порт Win32 доступен, но не совсем первоклассный гражданин. Git предоставляет пользователям хеши как номера версий; это обеспечивает гарантии (в том смысле, что один хэш всегда относится к одному и тому же контенту; злоумышленник не может изменить историю, не будучи обнаруженным), но может быть обременительным для пользователя. Git имеет уникальную концепцию отслеживания содержимого файлов, даже когда это содержимое перемещается между файлами, и рассматривает файлы как объекты первого уровня, но не отслеживает каталоги. Другая проблема с git заключается в том, что у него много операций (например, rebase), которые упрощают изменение истории (в некотором смысле - контент, на который ссылается хэш, никогда не изменится, но ссылки на этот хеш могут быть потеряны); некоторым пуристам (включая меня) это не очень нравится.
Bazaar работает достаточно быстро (очень быстро для деревьев с неглубокой историей, но в настоящее время плохо масштабируется с длиной истории), и его легко освоить тем, кто знаком с интерфейсами командной строки традиционных 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 представляет собой среду с тяжелыми концепциями, в отличие от инструментов, созданных для соответствия выбранным пользователем рабочим процессам, - но с тех пор я стал довольно комфортно работать с Это].
Стив Стритинг из проекта Ogre 3D только что (28 сентября 2009 г.) опубликовал в блоге запись на эту тему, в которой он проводит отличное и даже однозначное сравнение Git, Mercurial и Bazaar .
В конце концов, он находит сильные и слабые стороны у всех трех и без явного победителя. С другой стороны, он дает отличную таблицу, которая поможет вам решить, с какой из них пойти.
Это короткое чтение, и я очень рекомендую его.
В чем здесь люди видят относительные сильные и слабые стороны Git, Mercurial и Bazaar?
На мой взгляд Git сильная - это чистый базовый дизайн и очень богатый набор функций. Я считаю, что он также имеет лучшую поддержку для репозиториев с несколькими ветвями и управления рабочими процессами с большим количеством ветвей. Это очень быстро и имеет небольшой размер репозитория.
В нем есть некоторые полезные функции, но для их использования нужно приложить определенные усилия. К ним относятся видимая промежуточная промежуточная ара (индекс) между рабочей областью и базой данных репозитория, которая позволяет улучшить разрешение слияния в более сложных случаях, инкрементное завершение и завершение с грязным деревом; обнаружение переименований и копий с использованием эвристики подобия, а не их отслеживание с помощью каких-то идентификаторов файлов, что хорошо работает и позволяет указывать вину (аннотировать), что может отслеживать перемещение кода по файлам, а не только полное переименование.
Одним из его недостатков является отставание и неполная поддержка MS Windows. Другой предполагаемый недостаток заключается в том, что он не так хорошо документирован, как, например, Mercurial, и менее удобен для пользователя, чем конкуренты, но он меняется.
На мой взгляд, сильная сторона Mercurial заключается в его хорошей производительности и небольшом размере репозитория, а также в хорошей поддержке MS Windows.
Основным недостатком, на мой взгляд, является тот факт, что локальные ветки (несколько веток в одном репозитории) по-прежнему являются второсортными и странным и сложным образом реализуют теги. Также способ переименования файлов был неоптимальным (но этот перенос изменился). Mercurial не поддерживает слияние осьминогов (с более чем двумя родителями).
Из того, что я слышал и читал, основные преимущества Bazaar заключаются в простой поддержке централизованного рабочего процесса (что также является недостатком, поскольку централизованные концепции видны там, где этого не должно быть), отслеживание переименований как файлов, так и каталогов.
Его основным недостатком является производительность и размер репозитория для больших репозиториев с длинной нелинейной историей (производительность улучшилась, по крайней мере, для не слишком больших репозиториев), тот факт, что парадигма по умолчанию - одно ранчо на репозиторий (хотя вы можете настроить его для обмена данными) , и централизованные концепции (но и то, что я слышал об изменениях).
Git написан на C, сценариях оболочки и Perl и поддерживает сценарии; Mercurial написан на C (ядро, для производительности) и 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 и списков рассылки, а также сообщений в блогах и статей, сравнивающих различные системы контроля версий (некоторые из которых перечислены на странице GitComparison в Git Wiki).
У InfoQ есть хорошее сравнение .
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-dev «есть свою собачью еду».
- Mercurial значительно быстрее, чем bzr (он медленнее, чем git, хотя разница гораздо меньше).
- Пользователям SVN легче изучить Mercurial, чем Bazaar.
Некоторое время я использовал Bazaar, который мне очень нравился, но это были только небольшие проекты, и даже тогда это было довольно медленно. Так легко научиться, но не очень быстро. Хотя это очень х-платформа.
В настоящее время я использую Git, который мне очень нравится, поскольку версия 1.6 сделала его намного более похожим на другие VCS с точки зрения используемых команд.
Я думаю, что основные отличия моего опыта использования DVCS заключаются в следующем:
В общем, Bzr был великолепен, когда я работал над DVCS, но теперь я очень доволен Git и Github.
Это большой вопрос, который во многом зависит от контекста, и вам потребуется много времени, чтобы ввести его в одно из этих маленьких текстовых полей. Кроме того, все три из них кажутся в значительной степени похожими при использовании для обычных вещей, которые делает большинство программистов, поэтому даже понимание различий требует некоторых довольно эзотерических знаний.
Вы, вероятно, получите гораздо лучшие ответы, если сможете разбить свой анализ этих инструментов до точки, в которой у вас возникнут более конкретные вопросы.
ИМХО Bazaar выучить легче, чем git. У Git есть хорошая поддержка на github.com.
Я думаю, вам стоит попробовать использовать оба и решить, что вам больше подходит.
В чем здесь люди видят относительные сильные и слабые стороны Git, Mercurial и Bazaar?
Это очень открытый вопрос, граничащий с флеймбейтом.
Git самый быстрый, но все три достаточно быстры. Bazaar является наиболее гибким (он имеет прозрачную поддержку чтения и записи для репозиториев SVN) и очень заботится о пользовательском опыте. Mercurial находится где-то посередине.
У всех трех систем много фанатов. Я лично фанат Bazaar.
Какие проблемы следует учитывать при рассмотрении каждого из них друг с другом и с системами контроля версий, такими как SVN и Perforce?
Первые представляют собой распределенные системы. Последние представляют собой централизованные системы. Кроме того, Perforce является частной собственностью, а все остальные свободны, как на словах .
Централизованная система по сравнению с децентрализованной - гораздо более важный выбор, чем любая из упомянутых вами систем в своей категории.
Какие факторы вы бы приняли во внимание при планировании перехода с SVN на одну из этих распределенных систем контроля версий?
Во-первых, отсутствие хорошей замены TortoiseSVN. Хотя Bazaar работает над своим собственным вариантом Tortoise , по состоянию на сентябрь 2008 года его еще нет.
Затем обучение ключевых людей тому, как использование децентрализованной системы повлияет на их работу.
Наконец, интеграция с остальной частью системы, такой как системы отслеживания проблем, система ночной сборки, система автоматического тестирования и т. Д.
Ваша основная проблема будет заключаться в том, что это распределенные SCM, и поэтому потребуется немного изменить мышление пользователя. Как только люди привыкнут к этой идее, технические детали и шаблоны использования станут на свои места, но не стоит недооценивать это первоначальное препятствие, особенно в корпоративной среде. Помните, что все проблемы - это проблемы людей.
ddaa.myopenid.com упомянул об этом мимоходом, но я думаю, что стоит упомянуть еще раз: Bazaar может читать и писать в удаленные репозитории SVN. Это означает, что вы можете использовать Bazaar локально в качестве доказательства концепции, в то время как остальная часть команды все еще использует Subversion.
EDIT: Довольно много инструмента теперь есть какой - то способ взаимодействия с SVN, но теперь у меня есть личный опыт , который git svnработает очень хорошо. Пользуюсь уже несколько месяцев, икота минимальная.
На git есть хорошее видео Линуса Торвальдса. Он является создателем Git, поэтому он продвигает именно это, но в видео он объясняет, что такое распределенные SCM и почему они лучше централизованных. Есть много сравнения git (считается, что mercurial в порядке) и cvs / svn / perforce. Также есть вопросы из аудитории по поводу перехода на распределенную SCM.
Я нашел этот материал поучительным, и меня продали в распределенную SCM. Но, несмотря на усилия Линуса, мой выбор непостоянен. Причина в bitbucket.org, мне он показался лучше (щедрее), чем github.
Я должен сказать здесь одно предупреждение: у Линуса довольно агрессивный стиль, я думаю, он хочет быть смешным, но я не смеялся. Кроме того, видео замечательно, если вы плохо знакомы с распределенными SCM и думаете о переходе с SVN.
Распределенные системы контроля версий (DVCS) решают другие проблемы, чем централизованные VCS. Сравнивать их - все равно что сравнивать молотки и отвертки.
Централизованные системы VCS разработаны с намерением, что существует Один Истинный Источник, который Благословен и, следовательно, Хорош. Все разработчики работают (оформляют заказ) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся такими же благословенными. Единственная реальная разница между CVS, Subversion, ClearCase, Perforce, VisualSourceSafe и всеми другими CVCS заключается в рабочем процессе, производительности и интеграции, предлагаемых каждым продуктом.
Распределенные системы VCS разработаны с намерением, чтобы один репозиторий был не хуже любого другого, и что слияние из одного репозитория в другой - это просто еще одна форма связи. Любое семантическое значение относительно того, какому репозиторию следует доверять, навязывается извне процессом, а не самим программным обеспечением.
Реальный выбор между использованием того или иного типа - это организационный вопрос: если вашему проекту или организации требуется централизованное управление, тогда DVCS не будет запускаться. Если ожидается, что ваши разработчики будут работать по всей стране / миру без безопасных широкополосных подключений к центральному репозиторию, то DVCS, вероятно, ваше спасение. Если вам нужны оба, вы fsck'd.