Каковы относительные сильные и слабые стороны Git, Mercurial и Bazaar? [закрытый]
что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?
при рассмотрении каждого из них друг с другом и против систем управления версиями, таких как SVN и Perforce, какие вопросы следует учитывать?
при планировании миграции из SVN в одну из этих распределенных систем управления версиями, какие факторы вы бы рассмотрели?
16 ответов
Git очень быстрый, очень хорошо масштабируется и очень прозрачен в своих концепциях. Недостатком этого является то, что он имеет относительно крутую кривую обучения. Порт Win32 доступен, но не совсем первоклассный гражданин. Git предоставляет хэши как номера версий пользователям; это обеспечивает гарантии (в том, что один хэш всегда относится к одному и тому же содержимому; злоумышленник не может изменять историю без обнаружения), но может быть громоздким для пользователя. Git имеет уникальную концепцию отслеживания файлов содержимое, даже если это содержимое перемещается между файлами и просматривает файлы как объекты первого уровня, но не отслеживает каталоги. Другая проблема с git заключается в том, что имеет много операций (например,rebase), которые позволяют легко изменять историю (в некотором смысле-содержимое, на которое ссылается хэш, никогда не изменится, но ссылки на этот хэш могут быть потеряны); некоторым пуристам (включая меня) это не очень нравится.
базар достаточно быстрый (очень быстрый для деревьев с мелководьем история, но в настоящее время плохо масштабируется с длиной истории), и легко учиться тем, кто знаком с интерфейсами командной строки традиционных SCMs (CVS, SVN и т. д.). Win32 считается первоклассной целью своей командой разработчиков. Он имеет подключаемую архитектуру для различных компонентов и часто заменяет свой формат хранения; это позволяет им вводить новые функции (такие как лучшая поддержка интеграции с системами контроля версий на основе разных концепций) и улучшать спектакль. Команда Bazaar рассматривает отслеживание каталогов и переименование поддержки первоклассных функций. Хотя для всех ревизий доступны глобально уникальные идентификаторы идентификаторов ревизий, вместо хэшей содержимого для идентификации ревизий используются дерево-локальные revnos (стандартные номера ревизий, более похожие на те, которые используются svn или другими более обычными SCMs). Bazaar поддерживает "легкие проверки", в которых история хранится на удаленном сервере вместо копирования в локальную систему и автоматически упоминается по сети, когда это необходимо; в настоящее время это уникально среди DSCMs.
оба имеют некоторую форму интеграции SVN; однако bzr-svn значительно более способен, чем git-svn, в основном из-за изменений формата бэкэнда, введенных для этой цели. [обновление, по состоянию на 2014 год: сторонний коммерческий продукт SubGit обеспечивает двунаправленный интерфейс между SVN и Git, который сопоставим по точности с bzr-svn и значительно более отполирован; I сильно рекомендовать его использование по сравнению с git-svn, когда позволяют бюджетные и лицензионные ограничения].
Я не использовал Mercurial широко, и поэтому не могу прокомментировать его подробно-за исключением того, что он, как и Git, имеет хэш-адресацию контента для ревизий; также, как и Git, он не рассматривает каталоги как первоклассные объекты (и не может хранить пустой каталог). Однако он быстрее, чем любой другой DSCM, за исключением Git, и имеет гораздо лучшую интеграцию IDE (особенно затмение), чем любой из его конкурентов. Учитывая его характеристики производительности (которые лишь немного отстают от Git) и его превосходную кросс-платформенную и IDE-поддержку, Mercurial может быть убедительным для команд со значительным количеством win32-ориентированных или IDE-связанных членов.
одной из проблем при миграции из SVN является то, что интерфейсы GUI SVN и интеграция IDE являются более зрелыми, чем у любого из распределенных SCMs. Кроме того, если вы в настоящее время активно используете precommit автоматизация скриптов с SVN (т. е. требование прохождения модульных тестов перед фиксацией), вы, вероятно, захотите использовать инструмент, подобный программы pqm для автоматизации запросов слияния к вашим общим ветвям.
SVK-это DSCM, который использует Subversion в качестве резервного хранилища и имеет довольно хорошую интеграцию с SVN-ориентированными инструментами. Однако он имеет значительно худшие характеристики производительности и масштабируемости, чем любой другой крупный DSCM( даже Darcs), и его следует избегать для проектов которые могут расти большими с точки зрения либо длины истории, либо количества файлов.
[об авторе: я использую Git и Perforce для работы, а Bazaar для моих личных проектов и в качестве встроенной библиотеки; другие части организации моего работодателя используют Mercurial. В предыдущей жизни я построил много автоматизации вокруг SVN; до этого у меня был опыт работы с GNU Arch, BitKeeper, CVS и другими. Git был довольно отталкивающим поначалу - это было похоже на GNU Arch, поскольку будучи концепт-тяжелой средой, в отличие от наборов инструментов, построенных в соответствии с выбором рабочих процессов пользователя, но с тех пор я стал вполне комфортно с ним].
Стив Стритинг из проекта Ogre 3D just (9/28/2009) опубликовал запись в блоге на эту тему, где он делает большой и даже вручил сравнение Git, Mercurial и Bazaar.
В конце концов он находит сильные и слабые стороны со всеми тремя и нет явного победителя. С положительной стороны, он дает отличный стол, чтобы помочь вам решить, с которым идти.
его короткое чтение, и я настоятельно рекомендую его.
что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?
по-моему Git прочность свой чистый основной дизайн и очень богатый набор особенностей. Он также имеет, я думаю, лучшую поддержку для многоотраслевых репозиториев и управления отраслевыми рабочими процессами. Он очень быстрый и имеет небольшой размер репозитория.
Он имеет некоторые функции, которые полезны, но принять некоторые усилия, чтобы быть использованы для них. К ним относятся видимого промежуточный промежуточный Ara (индекс) между рабочей областью и базой данных репозитория, что позволяет улучшить разрешение слияния в более сложных случаях, инкрементное comitting и comitting с грязным деревом;определения переименовывает и копирует, используя эвристику подобия, а не отслеживает их, используя какие-то идентификаторы файлов, которые хорошо работают и которые позволяют обвинять (аннотировать) , которые могут следить за движением кода по файлам, а не только оптом переименует.
одним из его недостатков является то, что поддержка MS Windows отстает и не заполнена. Еще один очевидный недостаток заключается в том, что он не так хорошо документирован, как, например, Mercurial, и менее удобен для пользователей, чем конкуренция, но он меняется.
по-моему ртутный сила заключается в его хорошей производительности и небольшом размере репозитория, в его хорошей поддержке MS Windows.
главных недостатка, на мой взгляд, тот факт, что местные ветви (несколько ветвей в одном репозитории) по-прежнему являются гражданами второго класса, и странным и сложным образом он реализует теги. Также способ, которым он имеет дело с переименованиями файлов, был неоптимальным (но этот migth изменился). Mercurial не поддерживает слияния осьминогов (с более чем двумя родителями).
из того, что я слышал и читал main базар преимущества это простая поддержка централизованного рабочего процесса (что также является недостатком, с централизованными концепциями, видимыми там, где это не следовало), отслеживание переименование файлов и каталогов.
его основным недостатком являются производительность и размер репозитория для больших репозиториев с длинной нелинейной историей (производительность улучшилась, по крайней мере, для не слишком больших репозиториев), тот факт, что парадигма по умолчанию-одно ранчо на репозиторий (вы можете настроить его для обмена данными) и централизованные концепции (но это также из того, что я слышал изменения).
Git написан на C, скриптах оболочки и Perl и является сценарий; Mercurial написан на C (core, для производительности) и Python и предоставляет API для расширений; Bazaar написан на Python и предоставляет API для расширений.
при рассмотрении каждого из них друг с другом и против систем управления версиями, таких как SVN и Perforce, какие вопросы следует учитывать?
системы управления версиями, такие как Subversion (SVN), Perforce или ClearCase, являются централизованный системы контроля версий. Мерзавец, Mercurial, Bazaar (а также Darcs, Monotone и BitKeeper) являются распределенные системы контроля версий. Распределенные системы управления версиями позволяют значительно расширить диапазон рабочих процессов. Они позволяют использовать "publish when ready". Они имеют лучшую поддержку для ветвления и слияния, а также для ветвления тяжелых рабочих процессов. Вам не нужно доверять людям с доступом к фиксации, чтобы иметь возможность легко получать от них взносы.
при планировании миграции из SVN в one какие факторы из этих распределенных систем управления версиями вы бы рассмотрели?
одним из факторов, которые вы можете рассмотреть, является поддержка inetracting с SVN; Git имеет git-svn, Bazaar имеет bzr-svn, а Mercurial имеет расширение hgsubversion.
отказ от ответственности: Я пользователь Git и небольшой вкладчик времени, и смотреть (и участвовать в) список рассылки git. Я знаю Mercurial и Bazaar только из их документации, различных обсуждений IRC и рассылки списки, а также сообщения в блогах и статьи, сравнивающие различные системы контроля версий (некоторые из которых перечислены на GitComparison страница в Git Wiki).
Mercurial и Bazaar очень похожи на себя на поверхности. Они оба предоставляют базовый распределенный контроль версий, как в автономном фиксации и слиянии нескольких ветвей, оба написаны на python и оба медленнее, чем git. Есть много различий, когда вы вникаете в код, но для ваших повседневных задач они фактически одинаковы, хотя Mercurial, кажется, имеет немного больше импульса.
Git, ну, не для непосвященных. Это намного быстрее чем и Mercurial и Bazaar, и было написано управлять ядром Linux. Это самый быстрый из трех, а также самый мощный из трех, с большим отрывом. Инструменты управления журналом и фиксацией Git не имеют себе равных. Однако он также является самым сложным и самым опасным в использовании. Очень легко потерять фиксацию или разрушить репозиторий, особенно если вы не понимаете внутреннюю работу git.
взгляните на сравнение, сделанное недавно разработчиками Python:http://wiki.python.org/moin/DvcsComparison. Они выбрали Mercurial по трем важным причинам:
выбор пойти с Mercurial был сделан по трем важным причинам:
- согласно небольшому опросу, разработчики Python больше заинтересованы в использовании Mercurial чем в базаре или Git.
- Mercurial написан на Python, который конгруэнт с тенденцией python-dev "есть свою собственную собачью еду".
- Mercurial значительно быстрее, чем bzr (он медленнее, чем git, хотя и с гораздо меньшей разницей).
- Mercurial легче узнать для пользователей SVN, чем Bazaar.
Это большой вопрос, который зависит от контекста, который займет у вас много времени, чтобы ввести в одно из этих маленьких текстовых полей. Кроме того, все три из них кажутся существенно похожими, когда используются для обычных вещей, которые делают большинство программистов, поэтому даже понимание различий требует некоторых довольно эзотерических знаний.
вы, вероятно, получите гораздо лучшие ответы, если вы можете разбить свой анализ этих инструментов до точки, в которой у вас есть более конкретные вопросы.
базар ИМХО легче узнать, чем git. Git имеет хорошую поддержку в github.com.
Я думаю, вы должны попытаться использовать оба и решить, что подходит вам больше всего.
что люди здесь видят как относительные сильные и слабые стороны Git, Mercurial и Bazaar?
Это очень открытый вопрос, граничащий с flamebait.
Git самый быстрый, но все три достаточно быстры. Bazaar является самым гибким (он имеет прозрачную поддержку чтения и записи для репозиториев SVN) и много заботится о пользовательском опыте. Mercurial находится где-то посередине.
все три системы имеют много фанатов. Я лично я фанат базара.
при рассмотрении каждого из них друг с другом и против систем управления версиями, таких как SVN и Perforce, какие вопросы следует учитывать?
первые являются распределенными системами. Последние являются централизованными системами. Кроме того, Perforce является собственностью, в то время как все остальные свободны слова.
централизованный и децентрализованный-гораздо более важный выбор, чем любая из систем вы упомянули в его категории.
при планировании миграции из SVN в одну из этих распределенных систем управления версиями, какие факторы вы бы рассмотрели?
во-первых, отсутствие хорошей замены для TortoiseSVN. Хотя базар работает самостоятельно Черепаха вариант, но его еще нет, по состоянию на сентябрь 2008 года.
затем, обучение ключевых людей о том, как с помощью децентрализованной системы будет влиять на их работа.
наконец, интеграция с остальной частью системы, такой как трекеры выпуска, система ночной сборки, автоматизированная тестовая система и т. д.
некоторое время я использовал Bazaar, который мне очень понравился, но это были только небольшие проекты, и даже тогда это было довольно медленно. Так легко учиться, но не очень быстро. Это очень x-платформа, хотя.
в настоящее время я использую Git, который мне очень нравится, так как версия 1.6 сделала его гораздо более похожим на другие VCS с точки зрения команд для использования.
Я думаю, что основные различия для моего опыта использования DVCS таковы:
- Git имеет самое яркое сообщество, и это общие, чтобы увидеть статьи о Git
- GitHub действительно рулит. Launchpad.net это нормально, но ничего похожего на удовольствие от Github
- количество инструментов рабочего процесса для Git было большим. Она интегрирована повсюду. Есть некоторые для Bzr, но не так много или хорошо поддерживается.
в резюме Bzr было здорово, когда я резал зубы на DVCS, но теперь я очень доволен Git и Github.
распределенные системы управления версиями (DVCSs) решают различные проблемы, чем централизованные VCSs. Сравнивать их-все равно что сравнивать молотки и отвертки.
централизованный VCS системы разработаны с намерением, что есть один истинный источник, который благословлен, и, следовательно, хорошо. Все разработчики работают (checkout) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся аналогично благословленными. Единственная реальная разница между CVS, Subversion, ClearCase, Perforce, VisualSourceSafe и все другие CVCSes находятся в рабочем процессе, производительности и интеграции, которые предлагает каждый продукт.
распределенные VCS системы разработаны с намерением, что один репозиторий так же хорош, как и любой другой, и что слияния из одного репозитория в другой-это просто еще одна форма связи. Любое семантическое значение, которому следует доверять репозиторию, навязывается извне процессом, а не программным обеспечением себя.
реальный выбор между использованием одного типа или другого является организационным - если ваш проект или организация хочет централизованного управления, то DVCS не является стартером. Если ваши разработчики должны работать по всей стране / миру, без безопасных широкополосных подключений к центральному репозиторию, то DVCS, вероятно, ваше спасение. Если вам нужны оба, ты бы для fsck.
ваша главная проблема будет в том, что это распределенные SCMs, и как таковой требуют немного изменения в мышлении пользователя. Как только люди привыкнут к этой идее, технические детали и шаблоны использования встанут на свои места, но не стоит недооценивать это первоначальное препятствие, особенно в корпоративной обстановке. Помните, что все проблемы-это проблемы людей.
ddaa.myopenid.com упомянул это мимоходом, но я думаю, что стоит упомянуть еще раз: Bazaar может читать и писать в удаленные репозитории SVN. Это означает, что вы можете использовать Bazaar локально в качестве доказательства концепции, пока остальная часть команды все еще использует Subversion.
EDIT: почти весь инструмент теперь имеет некоторые способ взаимодействия с SVN, но теперь у меня есть личный опыт, что git svn работает очень хорошо. Я использую его в течение нескольких месяцев, с минимальная икота.
есть хорошее видео Линуса Торвальдса на git. Он является создателем Git, поэтому это то, что он продвигает, но в видео он объясняет, что такое распределенные SCMs и почему они лучше, чем централизованные. Существует много сравнения git (mercurial считается ОК) и cvs/svn/perforce. Есть также вопросы от аудитории относительно миграции в распределенный SCM.
Я нашел этот материал поучительным, и я продан распределенному SCM. Но, несмотря на усилия Лайнуса, мой выбор непостоянен. Причина в том, bitbucket.org, я нашел его лучше (более щедрым), чем github.
Я должен сказать здесь слово предупреждения: Линус имеет довольно агрессивный стиль, я думаю, что он хочет быть смешно но я не смеюсь. Кроме того, видео отлично подходит, если вы новичок в распределенных SCMs и думаете о переходе от SVN.