каковы относительные сильные и слабые стороны git, mercurial и bazaar?

<p>что люди здесь видят как относительные сильные и слабые стороны git, mercurial и bazaar?</p><p>какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как svn и perforce?</p><p>при планировании перехода от svn к одной из этих распределенных систем контроля версий, какие факторы вы бы учитывали?</p>

<p>git очень быстр, очень хорошо масштабируется и очень прозрачен в своих концепциях. недостатком этого является то, что у него относительно крутая кривая обучения. порт win32 доступен, но не совсем первоклассный гражданин. git выставляет хэши как номера версий пользователям; это обеспечивает гарантии (в том смысле, что один хэш всегда ссылается на одно и то же содержимое; злоумышленник не может изменить историю, не будучи обнаруженным), но может быть громоздким для пользователя. git имеет уникальную концепцию отслеживания содержимого файла, даже если это содержимое перемещается между файлами и просматривает файлы как объекты первого уровня, но не отслеживает каталоги. другая проблема с git - это много операций (таких как <i>перебазировать</i>) которые позволяют легко изменять историю (в некотором смысле - содержимое, на которое ссылается хеш, никогда не изменится, но ссылки на этот хэш могут быть потеряны); некоторым пуристам (включая меня) это не очень нравится.</p><p>базар достаточно быстрый (очень быстрый для деревьев с мелкой историей, но в настоящее время плохо масштабируется с длиной истории) и прост в освоении тем, кто знаком с интерфейсами командной строки традиционных scm (cvs, svn и т.д.). win32 считается первоклассной целью его команды разработчиков. он имеет подключаемую архитектуру для различных компонентов и часто заменяет свой формат хранения; это позволяет им внедрять новые функции (например, улучшенную поддержку интеграции с системами контроля версий на основе различных концепций) и повышать производительность. команда bazaar рассматривает отслеживание каталогов и поддержку переименования первоклассными функциями. хотя глобально уникальные идентификаторы идентификаторов ревизий доступны для всех ревизий, вместо хеш-содержимого контента для идентификации ревизий используются локальные древовидные ревно (стандартные номера ревизий, более схожие с теми, которые используются svn или другими более традиционными scm). bazaar поддерживает "облегченные проверки", в которых история хранится на удаленном сервере, а не копируется в локальную систему, и при необходимости автоматически передается по сети; в настоящее время это уникально среди dscm.</p><p>оба имеют некоторую форму интеграции svn; тем не менее, bzr-svn значительно более эффективен, чем git-svn, в основном из-за изменений в формате внутреннего интерфейса, введенных для этой цели. <i>[обновление от 2014 года: сторонний коммерческий продукт subgit обеспечивает двунаправленный интерфейс между svn и git, сравнимый по точности с bzr-svn и значительно улучшенный; я <b>сильно</b> рекомендовать его использование вместо git-svn, когда позволяют бюджетные и лицензионные ограничения].</i></p><p>я не использовал mercurial широко, и поэтому не могу комментировать его подробно - кроме как отметить, что он, как и git, имеет хеш-контент-адресацию для ревизий; также как и git, он не рассматривает каталоги как первоклассные объекты (и не может хранить пустой каталог). однако он работает быстрее, чем любой другой dscm, за исключением git, и имеет намного лучшую интеграцию ide (особенно для eclipse), чем любой из его конкурентов. учитывая его характеристики производительности (которые немного отстают от git), а также превосходную кроссплатформенность и поддержку ide, mercurial может быть привлекательным для команд со значительным количеством win32-ориентированных или связанных с ide участников.</p><p>одна из проблем при переходе с svn заключается в том, что внешние интерфейсы gui svn и интеграция ide более развиты, чем у любого из распределенных scm. кроме того, если вы в настоящее время интенсивно используете автоматизацию сценариев предварительной фиксации с svn (т. е. требовать прохождения модульных тестов, прежде чем можно будет продолжить фиксацию), вы, вероятно, захотите использовать инструмент, аналогичный <a href="https://launchpad.net/pqm">pqm</a> для автоматизации запросов на слияние ваших общих веток.</p><p>svk - это dscm, который использует subversion в качестве резервного хранилища и имеет довольно хорошую интеграцию с svn-ориентированными инструментами. однако он имеет значительно худшие характеристики производительности и масштабируемости, чем любой другой основной dscm (даже darcs), и его следует избегать для проектов, которые могут стать большими с точки зрения либо длины истории, либо количества файлов.</p><p>[об авторе: я использую git и perforce для работы и bazaar для своих личных проектов и в качестве встроенной библиотеки; другие части организации моего работодателя активно используют mercurial. в прошлой жизни я построил большую автоматизацию вокруг svn; до этого у меня был опыт работы с gnu arch, bitkeeper, cvs и другими. поначалу git был довольно унылым - он чувствовал себя как gnu arch, поскольку он является концептуально сложной средой, в отличие от наборов инструментов, созданных в соответствии с выбором рабочих процессов пользователя - но с тех пор я чтобы быть вполне комфортно с этим].</p>

<p>стив стрингинг из проекта ogre 3d (28.09.2009) опубликовал запись в блоге на эту тему, где он отлично справляется и даже вручает <a href="http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/">сравнение git, mercurial и bazaar</a> .</p><p>в конце концов он находит сильные и слабые стороны со всеми тремя и без явного победителя. с другой стороны, он дает отличную таблицу, чтобы помочь вам решить, с чем идти.</p><p><img src="https://i.stack.imgur.com/hlrmt.png" alt="alt text"></p><p>это краткое чтение, и я очень рекомендую его.</p>

<hr><blockquote><em> что люди здесь видят как относительные сильные и слабые стороны git, mercurial и bazaar? </em></blockquote><p>на мой взгляд <strong> сила git </strong> заключается в его чистом базовом дизайне и очень богатом наборе функций. он также имеет лучшую поддержку для многоотраслевых репозиториев и управления тяжелыми рабочими процессами. это очень быстро и имеет небольшой размер хранилища.</p><p>он имеет некоторые функции, которые полезны, но требуют определенных усилий для их использования. к ним относятся <em> visible </em> промежуточная промежуточная стадия (индекс) между рабочей областью и базой данных репозитория, которая позволяет лучше разрешать слияния в более сложных случаях, инкрементные комитеты и коммиты с грязным деревом; <em> обнаружение </em> переименовывает и копирует с использованием эвристики сходства, а не отслеживает их с помощью какого-либо идентификатора файла, который хорошо работает и допускает обвинение (аннотирование), которое может следовать за перемещением кода между файлами и не только оптовые переименования.</p><p>одним из его недостатков является то, что поддержка ms windows отстает и не является полной. еще одним недостатком является то, что он не так хорошо документирован, как, например, mercurial, и менее удобен для пользователей, чем конкуренты, но он меняется.</p><p>на мой взгляд <strong> сила mercurial </strong> заключается в его хорошей производительности и небольшом размере репозитория, в его хорошей поддержке ms windows.</p><p>основным недостатком, на мой взгляд, является тот факт, что локальные ветви (несколько ветвей в одном репозитории) по-прежнему являются гражданами второго сорта и странным и сложным образом реализуют теги. также способ, которым это имеет дело с переименованиями файлов, был неоптимальным (но это изменение изменилось) mercurial не поддерживает слияния осьминогов (с более чем двумя родителями).</p><p>из того, что я слышал и читал, основные <strong> преимущества bazaar </strong> заключаются в простоте поддержки централизованного рабочего процесса (что также является недостатком, когда централизованные концепции видны там, где их не должно быть) ), отслеживание переименований как файлов, так и каталогов.</p><p>его основным недостатком является производительность и размер репозитория для больших репозиториев с длинной нелинейной историей (производительность улучшилась, по крайней мере, для не слишком больших репозиториев), тот факт, что парадигма по умолчанию - одно ранчо на репозиторий (хотя вы можете настроить его для совместного использования данных) и централизованные концепции (но это также из того, что я слышал изменения).</p><p>git написан на c, сценариях shell и perl, и является сценарием; mercurial написан на c (ядро, для производительности) и python и предоставляет api для расширений; базар написан на python и предоставляет api для расширений.</p><hr><blockquote><em> какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как svn и perforce? </em></blockquote><p>системы контроля версий, такие как subversion (svn), perforce или clearcase, являются <em> централизованными </em> системами контроля версий. git, mercurial, bazaar (а также darcs, monotone и bitkeeper) являются <em> распределенными </em> системами контроля версий. распределенные системы контроля версий обеспечивают гораздо более широкий диапазон рабочих процессов. они позволяют использовать "публиковать, когда готовы". у них улучшена поддержка ветвления и слияния, а также рабочих процессов с интенсивным ветвлением. вам не нужно доверять людям с доступом к коммитам, чтобы иметь возможность получать вклады от них простым способом.</p><hr><blockquote><em> при планировании перехода с svn на одну из этих распределенных систем контроля версий, какие факторы вы бы учитывали? </em></blockquote><p>одним из факторов, который вы можете рассмотреть, является поддержка невмешательства в svn; у git есть git-svn, у bazaar есть bzr-svn, а у mercurial есть расширение hgsubversion.</p><p><strong> отказ от ответственности: </strong> я являюсь пользователем git и небольшим участником, и наблюдаю (и участвую) в списке рассылки git. я знаю mercurial и bazaar только по их документации, различным обсуждениям irc и спискам рассылки, а также публикациям в блогах и статьям, сравнивающим различные системы контроля версий (некоторые из которых перечислены на странице <a href="http://git.or.cz/gitwiki/gitcomparison">gitcomparison</a> на git wiki).</p>

<p>infoq имеет <a href="http://www.infoq.com/articles/dvcs-guide">хорошее сравнение</a> .</p>

<p>mercurial и bazaar очень похожи на поверхности. они оба обеспечивают базовое управление распределенной версией, как при автономной фиксации и слиянии нескольких ветвей, так и написаны в python и работают медленнее, чем git. когда вы углубляетесь в код, есть много различий, но для ваших повседневных задач они практически одинаковы, хотя, похоже, mercurial обладает немного большей динамикой.</p><p>git, ну, не для непосвященных. он намного быстрее, чем mercurial и bazaar, и был написан для управления ядром linux. это самый быстрый из трех, и это также самый мощный из трех, с большим отрывом. средства управления журналом и фиксацией в git не имеют себе равных. тем не менее, это также самый сложный и самый опасный в использовании. очень легко потерять коммит или испортить репозиторий, особенно если вы не понимаете внутреннюю работу git.</p>

<p>посмотрите на сравнение, сделанное недавно разработчиками python: <a href="http://wiki.python.org/moin/dvcscomparison">http://wiki.python.org/moin/dvcscomparison</a> . они выбрали mercurial по трем важным причинам:</p><blockquote> <p>выбор mercurial был сделан по трем важным причинам:</p> <ul> <li>согласно небольшому опросу, python разработчики больше заинтересованы в использовании mercurial, чем в bazaar или git.</li> <li>mercurial написан на python, что согласуется с тенденцией python-dev "есть свою собачью еду".</li> <li>mercurial значительно быстрее, чем bzr (он медленнее, чем git, хотя и с гораздо меньшей разницей).</li> <li>mercurial проще для пользователей svn, чем bazaar.</li> </ul> <p>(из <a href="http://www.python.org/dev/peps/pep-0374/">http://www.python.org/dev/peps/pep-0374/</a> )</p> </blockquote>

<p>sun провела оценку <a href="http://opensolaris.org/os/community/tools/scm/git-eval.txt">git</a> , <a href="http://opensolaris.org/os/community/tools/scm/mercurial-eval.html">mercurial</a> и <a href="http://opensolaris.org/os/community/tools/scm/bzr-eval/">bazaar</a> в качестве кандидатов на замену sun teamware vcs для базы кода solaris. я нашел это очень интересным.</p>

<p>очень важная <strong> пропущенная </strong> вещь на базаре - cp. вы не можете иметь несколько файлов с одинаковой историей, как в svn, см., например, <a href="https://lists.ubuntu.com/archives/bazaar/2007q3/029792.html">здесь</a> и <a href="https://bugs.launchpad.net/bzr/+bug/269095">здесь</a> . если вы не планируете использовать cp, bzr - отличная (и очень простая в использовании) замена svn.</p>

<p>некоторое время я использовал bazaar, который мне очень понравился, но это были только небольшие проекты, и даже тогда они были довольно медленными. так легко учиться, но не супер быстро. это очень х-платформа, хотя.</p><p>в настоящее время я использую git, который мне очень нравится, так как версия 1.6 сделала его намного более похожим на другие vcs с точки зрения команд, которые нужно использовать.</p><p>я думаю, что основные различия в моем опыте использования dvcs заключаются в следующем:</p><ol> <li>у git самое оживленное сообщество, и часто можно увидеть статьи о git</li> <li> <a href="http://github.com">github</a> действительно качается. launchpad.net в порядке, но ничего подобного удовольствию от github</li> <li>количество инструментов рабочего процесса для git было огромным. это интегрировано повсеместно. есть некоторые для bzr, но не так много или в хорошем состоянии.</li> </ol><p>таким образом, bzr был великолепен, когда я резал зубы на dvcs, но теперь я очень доволен git и github.</p>

<p>ваша главная проблема будет состоять в том, что это <strong>распределенные</strong> scm, и поэтому они должны немного изменить мышление пользователя. как только люди привыкнут к этой идее, технические детали и схемы использования станут на свои места, но не стоит недооценивать это начальное препятствие, особенно в корпоративной среде. помните, что все проблемы - это проблемы людей.</p>

<p>базар имхо легче учить, чем мерзавец. git имеет хорошую поддержку на github.com.</p><p>я думаю, что вы должны попытаться использовать оба и решить, что подходит вам больше всего.</p>

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

<blockquote> <p>что люди здесь видят как относительные сильные и слабые стороны git, mercurial и bazaar?</p> </blockquote><p>это очень открытый вопрос, граничащий с приманкой.</p><p>git самый быстрый, но все три достаточно быстрые. базар является наиболее гибким (имеет прозрачную поддержку чтения и записи для svn-репозиториев) и очень заботится о взаимодействии с пользователем. mercurial где-то посередине.</p><p>все три системы имеют множество фанатов. я лично фанат bazaar.</p><blockquote> <p>какие вопросы следует учитывать при рассмотрении каждого из них друг с другом и против систем контроля версий, таких как svn и perforce?</p> </blockquote><p>первые являются распределенными системами. последние являются централизованными системами. кроме того, perforce является частной собственностью, а все остальные бесплатны <a href="http://www.gnu.org/philosophy/free-sw.html">как в речи</a> .</p><p>централизованное или децентрализованное решение - гораздо более важный выбор, чем любая из систем, упомянутых вами в своей категории.</p><blockquote> <p>при планировании перехода от svn к одной из этих распределенных систем контроля версий, какие факторы вы бы учитывали?</p> </blockquote><p>во-первых, отсутствие хорошей замены tortoisesvn. хотя bazaar работает самостоятельно <a href="http://bazaar-vcs.org/tortoisebzr">вариант с черепахой</a> , но его еще нет, по состоянию на сентябрь 2008 года.</p><p>затем обучение ключевых людей тому, как использование децентрализованной системы повлияет на их работу.</p><p>наконец, интеграция с остальной системой, такой как системы отслеживания ошибок, система ночной сборки, автоматизированная система тестирования и т.д.</p>

<p>ddaa.myopenid.com упомянул об этом попутно, но я думаю, что стоит упомянуть еще раз: bazaar может читать и писать в удаленные репозитории svn. это означает, что вы можете использовать bazaar локально в качестве подтверждения концепции, в то время как остальная часть команды все еще использует subversion.</p><p>правка: практически все инструменты теперь имеют <em> некоторый </em> способ взаимодействия с svn, но теперь у меня есть личный опыт работы <code>git svn</code> <strong>чрезвычайно</strong> = хорошо я использовал его в течение нескольких месяцев, с минимальными отклонениями.</p>

<p>на git есть хорошее видео линуса торвальдса. он является создателем git, так что это то, что он продвигает, но в видео он объясняет, что такое распределенные scm и почему они лучше, чем централизованные. существует много сравнений между git (mercurial считается нормальным) и cvs/svn/perforce. есть также вопросы от аудитории относительно перехода на распределенную scm.</p><p>я нашел этот материал поучительным, и я продан распределенному скм. но, несмотря на усилия линуса, мой выбор - mercurial. причина в bitbucket.org, я нашел его лучше (более щедрым), чем github.</p><p>я должен сказать здесь слово предупреждения: у линуса довольно агрессивный стиль, я думаю, что он хочет быть смешным, но я не смеялся. кроме того, видео отличное, если вы новичок в распределенных scm и думаете о переходе с svn.</p><p> <a href="http://www.youtube.com/watch?v=4xpnkhjaok8">http://www.youtube.com/watch?v=4xpnkhjaok8</a> </p>

<p>распределенные системы контроля версий (dvcs) решают проблемы, отличные от централизованных vcs. сравнивать их - все равно что сравнивать молотки и отвертки.</p><p> <a href="http://en.wikipedia.org/wiki/revision\_control">централизованные vcs</a> системы разрабатываются с намерением, чтобы был один истинный источник, который является благословенным, и, следовательно, хорошим. все разработчики работают (извлечение) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся аналогично благословенными. единственная реальная разница между cvs, subversion, clearcase, perforce, visualsourcesafe и всеми другими cvcs заключается в рабочем процессе, производительности и интеграции, которые предлагает каждый продукт.</p><p> <a href="http://en.wikipedia.org/wiki/distributed\_revision\_control">распределенная vcs</a> системы разрабатываются с намерением, чтобы один репозиторий был так же хорош, как и любой другой, и что слияние из одного репозитория в другое - это просто еще одна форма общения. любая семантическая ценность того, какому хранилищу следует доверять, навязывается извне процессом, а не самим программным обеспечением.</p><p>реальный выбор между использованием одного типа или другого - организационный - если ваш проект или организация хочет централизованного управления, то dvcs не является началом. если ожидается, что ваши разработчики будут работать по всей стране/миру, без безопасных широкополосных подключений к центральному репозиторию, то dvcs, вероятно, ваше спасение. если вам нужны оба, вы fsck'd.</p>