Кстати, хотелось бы увидеть процент использования различных систем DVCS.
серджиол
Ответы:
146
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 представляет собой среду с тяжелыми концепциями, в отличие от инструментов, созданных для соответствия выбранным пользователем рабочим процессам, - но с тех пор я стал довольно комфортно работать с Это].
Привет. Я просто хочу, чтобы вы знали, что cscvs все еще используется для запуска импорта кода Launchpad, и у меня была выпущена версия Canonical, когда я там работал.
ddaa
19
Стив Стритинг из проекта Ogre 3D только что (28 сентября 2009 г.) опубликовал в блоге запись на эту тему, в которой он проводит отличное и даже однозначное сравнение Git, Mercurial и Bazaar .
В конце концов, он находит сильные и слабые стороны у всех трех и без явного победителя. С другой стороны, он дает отличную таблицу, которая поможет вам решить, с какой из них пойти.
@gavenkoa, базар интуитивно понятен людям из SVN. Если вы пришли из git, то у вас есть ментальная модель, которая ближе к основам bazaar, но очень, очень далека от его интерфейса. (... наличие такого толстого слоя абстракции между основами и интерфейсом позволяет bzr быть дружелюбным по отношению к людям, знакомым с моделью SVN).
Чарльз Даффи
2
@CharlesDuffy Mercurial также имеет интуитивно понятные имена для команд и не мертв (разработка Bazaar была остановлена 2 года назад, и Canonical отклонила ее, да, Git + github выиграли игру DVCS ). Я никогда не понимаю схему именования git, поэтому лично предпочитаю HG. Слишком тяжело драться с парнями Git-lovers ((
gavenkoa
@gavenkoa, основные имена команд bzr соответствуют SVN, поэтому я снова не вижу, что может быть в них не интуитивно понятным (для пользователя SVN). Да, конечно, разработка мертва. Я не утверждаю, что bzr практичен в использовании - только то, что конкретная критика была необоснованной.
Чарльз Даффи
1
@gavenkoa, ... Я также был известен тем, что защищал аспекты BitKeeper, несмотря на то, что у меня было довольно большое недовольство разработчиками / владельцами программного обеспечения (его основа публично задокументирована ... хотя Ларри действительно позвонил мне однажды, чтобы описать их конец того, что произошло, и я признаю, что теперь понимаю обе стороны). Тот факт, что я защищаю SCM, не означает, что я действительно рекомендую его использовать. :)
Чарльз Даффи
15
В чем здесь люди видят относительные сильные и слабые стороны 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).
К вашему сведению - bzr-svn намного более эффективен, чем git-svn, в том смысле, что он двунаправлен: я могу запустить «bzr branch svn: // ...», а затем слить мои изменения обратно на svn-сервер - где они будут храниться с метаданными, которые распознают другие клиенты bzr.
Чарльз Даффи,
2
Я hg dev и немного присмотрелся к дизайну Git. Я рад видеть, что они оба обрабатывают историю единственным разумным способом для распределенной среды: на высоком уровне они оба являются ациклическим графиком коммитов, а на более низком уровне они оба позволяют коммитить ссылочные манифесты, которые ссылаются на файлы (blobs в Git ). У Mercurial есть анонимные ветки (которые, AFAIK не существует в Git), у него есть ветки с закладками (очень похоже на ветки Git, но без push / pull), и у него есть именованные ветки (имя ветки записывается в фиксации - они также не в Git).
Этот ответ можно улучшить, если резюмировать сказанное сравнение.
lindes
7
Mercurial и Bazaar внешне очень похожи друг на друга. Оба они обеспечивают базовое распределенное управление версиями, как при автономной фиксации и слиянии нескольких веток, оба написаны на Python и работают медленнее, чем git. Как только вы углубитесь в код, вы увидите много различий, но для повседневных задач они практически одинаковы, хотя Mercurial, похоже, имеет немного больше возможностей.
Git, ну, не для непосвященных. Он намного быстрее, чем Mercurial и Bazaar, и был написан для управления ядром Linux. Это самый быстрый из трех, а также самый мощный из трех, с большим отрывом. Журналы Git и инструменты управления фиксацией не имеют себе равных. Однако он также является наиболее сложным и опасным в использовании. Очень легко потерять фиксацию или испортить репозиторий, особенно если вы не понимаете внутреннюю работу git.
Mercurial действительно на одном уровне с Git. По производительности большой разницы нет. Но базар работает медленнее, чем Mercurial и Git.
Джошуа Партоги
@jpartogi - показатели производительности Bazaar улучшаются намного быстрее, чем у его конкурентов, поэтому я буду осторожен, делая такое утверждение - особенно с рефакторингом хранилища, который доступен в качестве предварительной версии в текущих выпусках и планируется по умолчанию в 2.0.
Mozilla и Sun также используют Mercurial по той же причине.
Джошуа Партоги
2
bzr также написан на Python, действительно медленнее, чем hg, но с быстро сужающейся границей - и, как пользователь как Bazaar, так и Mercurial, я / категорически / не согласен с утверждением "легче изучить".
Чарльз Даффи,
1
Все они все еще развиваются. Я выбрал Bazaar в качестве DCVS для начала, потому что думал, что это самый простой (но не очень) и Launchpad.net. Это было довольно медленно. Git на OSX выглядит нормально, но с плохой поддержкой Windows. Поскольку проекты Python и Google уже приняли его, и из-за TortoiseHg я перехожу на Mercurial. Я думаю, что Mercurial набирает критическую массу по сравнению с Bazaar и будет там. И Git будет делать свое дело, всегда фокусируясь на Posix, поэтому никогда не будет по-настоящему доминирующим.
Ник
5
Sun провела оценку git , Mercurial и Bazaar как кандидатов на замену Sun Teamware VCS для базы кода Solaris. Мне это показалось очень интересным.
эти оценки несколько устарели, более новые версии изменили некоторые из указанных там недостатков.
hayalci 01
2
Очень важная вещь, отсутствующая в базаре, - это cp. Вы не можете иметь несколько файлов с общей историей, как в SVN, см., Например, здесь и здесь . Если вы не планируете использовать cp, bzr - отличная (и очень простая в использовании) замена svn.
Это отсутствует по замыслу - cp не может быть добавлен без создания ряда случаев, когда трудно или невозможно быть уверенным в правильности выполнения слияния между веткой, в которой произошли копии и изменения, и другой веткой с изменениями, но без копии .
Чарльз Даффи,
Конечно, но об этом нужно знать - и это будет очень полезная функция для многих случаев использования (например, разделение файла на два разных и сохранение истории для обоих). На самом деле это единственная причина, по которой я до сих пор использую Subversion для определенных проектов - где слияние не имеет значения, а копирование - нет,
Давиде
2
Некоторое время я использовал Bazaar, который мне очень нравился, но это были только небольшие проекты, и даже тогда это было довольно медленно. Так легко научиться, но не очень быстро. Хотя это очень х-платформа.
В настоящее время я использую Git, который мне очень нравится, поскольку версия 1.6 сделала его намного более похожим на другие VCS с точки зрения используемых команд.
Я думаю, что основные отличия моего опыта использования DVCS заключаются в следующем:
У Git самое яркое сообщество, и часто можно увидеть статьи о Git.
GitHub действительно крут. Launchpad.net в порядке, но ничего подобного удовольствия от Github
Количество инструментов рабочего процесса для Git было огромным. Он интегрирован повсюду. Есть некоторые для Bzr, но не так много или в таком хорошем состоянии.
В общем, Bzr был великолепен, когда я работал над DVCS, но теперь я очень доволен Git и Github.
Вы имеете в виду «сейчас» очень счастлив, а не «не очень счастлив», верно?
Чарльз Даффи,
Спасибо, Чарльз! Здесь
допущена оплошность
1
Это большой вопрос, который во многом зависит от контекста, и вам потребуется много времени, чтобы ввести его в одно из этих маленьких текстовых полей. Кроме того, все три из них кажутся в значительной степени похожими при использовании для обычных вещей, которые делает большинство программистов, поэтому даже понимание различий требует некоторых довольно эзотерических знаний.
Вы, вероятно, получите гораздо лучшие ответы, если сможете разбить свой анализ этих инструментов до точки, в которой у вас возникнут более конкретные вопросы.
Mercurial так же прост, как и Bazaar, относительно быстр по сравнению с git и имеет хорошую поддержку на Bitbucket. Так что еще вы могли спросить?
Джошуа Партоги,
1
В чем здесь люди видят относительные сильные и слабые стороны Git, Mercurial и Bazaar?
Это очень открытый вопрос, граничащий с флеймбейтом.
Git самый быстрый, но все три достаточно быстры. Bazaar является наиболее гибким (он имеет прозрачную поддержку чтения и записи для репозиториев SVN) и очень заботится о пользовательском опыте. Mercurial находится где-то посередине.
У всех трех систем много фанатов. Я лично фанат Bazaar.
Какие проблемы следует учитывать при рассмотрении каждого из них друг с другом и с системами контроля версий, такими как SVN и Perforce?
Первые представляют собой распределенные системы. Последние представляют собой централизованные системы. Кроме того, Perforce является частной собственностью, а все остальные свободны, как на словах .
Централизованная система по сравнению с децентрализованной - гораздо более важный выбор, чем любая из упомянутых вами систем в своей категории.
Какие факторы вы бы приняли во внимание при планировании перехода с SVN на одну из этих распределенных систем контроля версий?
Во-первых, отсутствие хорошей замены TortoiseSVN. Хотя Bazaar работает над своим собственным вариантом Tortoise , по состоянию на сентябрь 2008 года его еще нет.
Затем обучение ключевых людей тому, как использование децентрализованной системы повлияет на их работу.
Наконец, интеграция с остальной частью системы, такой как системы отслеживания проблем, система ночной сборки, система автоматического тестирования и т. Д.
Для записи, на текущей странице указано: «Начиная с версии 1.6 Bazaar, TortoiseBZR включен в официальный установщик», так что, похоже, он стал зрелым.
PhiLho
1
Ваша основная проблема будет заключаться в том, что это распределенные 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.
Между CVS, SVN и VisualSourceSafe (не более 3) есть очень существенные различия, которые серьезно влияют на их полезность - и это не только проблемы рабочего процесса и / или интеграции.
Мерф
Я использовал все три из них, и технически вы правы, но с точки зрения высокого уровня мой ответ также верен. Контроль версий для более чем одного разработчика - это организационный инструмент; Пока инструмент отвечает потребностям организации, это все, что имеет значение в долгосрочной перспективе.
Ответы:
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 сильная - это чистый базовый дизайн и очень богатый набор функций. Я считаю, что он также имеет лучшую поддержку для репозиториев с несколькими ветвями и управления рабочими процессами с большим количеством ветвей. Это очень быстро и имеет небольшой размер репозитория.
В нем есть некоторые полезные функции, но для их использования нужно приложить определенные усилия. К ним относятся видимая промежуточная промежуточная ара (индекс) между рабочей областью и базой данных репозитория, которая позволяет улучшить разрешение слияния в более сложных случаях, инкрементное завершение и завершение с грязным деревом; обнаружение переименований и копий с использованием эвристики подобия, а не их отслеживание с помощью каких-то идентификаторов файлов, что хорошо работает и позволяет указывать вину (аннотировать), что может отслеживать перемещение кода по файлам, а не только полное переименование.
Одним из его недостатков является отставание и неполная поддержка MS Windows. Другой предполагаемый недостаток заключается в том, что он не так хорошо документирован, как, например, Mercurial, и менее удобен для пользователя, чем конкуренты, но он меняется.
На мой взгляд, сильная сторона Mercurial заключается в его хорошей производительности и небольшом размере репозитория, а также в хорошей поддержке MS Windows.
Основным недостатком, на мой взгляд, является тот факт, что локальные ветки (несколько веток в одном репозитории) по-прежнему являются второсортными и странным и сложным образом реализуют теги. Также способ переименования файлов был неоптимальным (но этот перенос изменился). Mercurial не поддерживает слияние осьминогов (с более чем двумя родителями).
Из того, что я слышал и читал, основные преимущества Bazaar заключаются в простой поддержке централизованного рабочего процесса (что также является недостатком, поскольку централизованные концепции видны там, где этого не должно быть), отслеживание переименований как файлов, так и каталогов.
Его основным недостатком является производительность и размер репозитория для больших репозиториев с длинной нелинейной историей (производительность улучшилась, по крайней мере, для не слишком больших репозиториев), тот факт, что парадигма по умолчанию - одно ранчо на репозиторий (хотя вы можете настроить его для обмена данными) , и централизованные концепции (но и то, что я слышал об изменениях).
Git написан на C, сценариях оболочки и Perl и поддерживает сценарии; Mercurial написан на C (ядро, для производительности) и Python и предоставляет API для расширений; Bazaar написан на Python и предоставляет API для расширений.
Системы контроля версий, такие как Subversion (SVN), Perforce или ClearCase, представляют собой централизованные системы контроля версий. Git, Mercurial, Bazaar (а также Darcs, Monotone и BitKeeper) - это распределенные системы контроля версий. Распределенные системы контроля версий позволяют использовать гораздо более широкий диапазон рабочих процессов. Они позволяют использовать «опубликовать, когда будете готовы». Они лучше поддерживают ветвление и слияние, а также рабочие процессы с большим количеством ветвей. Вам не нужно доверять людям с доступом к коммитам, чтобы иметь возможность легко получать от них вклад.
Один из факторов, который вы, возможно, захотите принять во внимание, - это поддержка взаимодействия с 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 по трем важным причинам:
источник
Sun провела оценку git , Mercurial и Bazaar как кандидатов на замену Sun Teamware VCS для базы кода Solaris. Мне это показалось очень интересным.
источник
Очень важная вещь, отсутствующая в базаре, - это cp. Вы не можете иметь несколько файлов с общей историей, как в SVN, см., Например, здесь и здесь . Если вы не планируете использовать cp, bzr - отличная (и очень простая в использовании) замена svn.
источник
Некоторое время я использовал Bazaar, который мне очень нравился, но это были только небольшие проекты, и даже тогда это было довольно медленно. Так легко научиться, но не очень быстро. Хотя это очень х-платформа.
В настоящее время я использую Git, который мне очень нравится, поскольку версия 1.6 сделала его намного более похожим на другие VCS с точки зрения используемых команд.
Я думаю, что основные отличия моего опыта использования DVCS заключаются в следующем:
В общем, Bzr был великолепен, когда я работал над DVCS, но теперь я очень доволен Git и Github.
источник
Это большой вопрос, который во многом зависит от контекста, и вам потребуется много времени, чтобы ввести его в одно из этих маленьких текстовых полей. Кроме того, все три из них кажутся в значительной степени похожими при использовании для обычных вещей, которые делает большинство программистов, поэтому даже понимание различий требует некоторых довольно эзотерических знаний.
Вы, вероятно, получите гораздо лучшие ответы, если сможете разбить свой анализ этих инструментов до точки, в которой у вас возникнут более конкретные вопросы.
источник
ИМХО Bazaar выучить легче, чем git. У Git есть хорошая поддержка на github.com.
Я думаю, вам стоит попробовать использовать оба и решить, что вам больше подходит.
источник
Это очень открытый вопрос, граничащий с флеймбейтом.
Git самый быстрый, но все три достаточно быстры. Bazaar является наиболее гибким (он имеет прозрачную поддержку чтения и записи для репозиториев SVN) и очень заботится о пользовательском опыте. Mercurial находится где-то посередине.
У всех трех систем много фанатов. Я лично фанат Bazaar.
Первые представляют собой распределенные системы. Последние представляют собой централизованные системы. Кроме того, Perforce является частной собственностью, а все остальные свободны, как на словах .
Централизованная система по сравнению с децентрализованной - гораздо более важный выбор, чем любая из упомянутых вами систем в своей категории.
Во-первых, отсутствие хорошей замены 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.
http://www.youtube.com/watch?v=4XpnKHJAok8
источник
Распределенные системы контроля версий (DVCS) решают другие проблемы, чем централизованные VCS. Сравнивать их - все равно что сравнивать молотки и отвертки.
Централизованные системы VCS разработаны с намерением, что существует Один Истинный Источник, который Благословен и, следовательно, Хорош. Все разработчики работают (оформляют заказ) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся такими же благословенными. Единственная реальная разница между CVS, Subversion, ClearCase, Perforce, VisualSourceSafe и всеми другими CVCS заключается в рабочем процессе, производительности и интеграции, предлагаемых каждым продуктом.
Распределенные системы VCS разработаны с намерением, чтобы один репозиторий был не хуже любого другого, и что слияние из одного репозитория в другой - это просто еще одна форма связи. Любое семантическое значение относительно того, какому репозиторию следует доверять, навязывается извне процессом, а не самим программным обеспечением.
Реальный выбор между использованием того или иного типа - это организационный вопрос: если вашему проекту или организации требуется централизованное управление, тогда DVCS не будет запускаться. Если ожидается, что ваши разработчики будут работать по всей стране / миру без безопасных широкополосных подключений к центральному репозиторию, то DVCS, вероятно, ваше спасение. Если вам нужны оба, вы fsck'd.
источник