Что здесь видят люди как относительные сильные и слабые стороны 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 и значительно более полирован; я strong рекомендуют использовать его по сравнению с git -svn, если разрешены ограничения по бюджету и лицензированию.
Я не использовал Mercurial экстенсивно и поэтому не могу комментировать его подробно - за исключением того, что он, как и Git, имеет адресную хэш-адресацию для ревизий; также как Git, он не рассматривает каталоги как объекты первого класса (и не может хранить пустой каталог). Однако он быстрее, чем любой другой DSCM, за исключением Git, и имеет гораздо лучшую интеграцию IDE (особенно для Eclipse), чем любой из ее конкурентов. Учитывая его рабочие характеристики (которые отстают лишь немного отстают от Git) и обеспечивают превосходную кросс-платформенную поддержку и поддержку IDE, Mercurial может быть привлекательным для команд со значительным числом элементов, связанных с win32-ориентированным или IDE-интерфейсом.
Одна из проблем при переносе из SVN заключается в том, что интерфейсы GUI SVN и интеграция IDE более зрелые, чем у любого из распределенных SCM. Кроме того, если вы в настоящее время сильно используете автоматизацию precommit script с SVN (т.е. Требуя, чтобы модульные тесты проходили до того, как коммит может продолжаться), вы, вероятно, захотите использовать инструмент, похожий на PQM для автоматизации запросов слияния к вашим общим ветвям.
SVK - это DSCM, который использует Subversion в качестве своего резервного хранилища и имеет неплохую интеграцию с SVN-ориентированными инструментами. Тем не менее, он имеет значительно худшие характеристики производительности и масштабируемости, чем любые другие основные DSCM (даже Darcs), и их следует избегать для проектов, которые могут расти как по длине, так и по количеству файлов.
[Об авторе: я использую Git и Perforce для работы, и Bazaar для своих личных проектов и как встроенную библиотеку; другие части моей организации-работодателя сильно используют Mercurial. В предыдущей жизни я построил большую автоматизацию вокруг SVN; до этого у меня есть опыт работы с GNU Arch, BitKeeper, CVS и другими. Git был совершенно неактуальным - он был похож на GNU Arch, поскольку являлся концептуально тяжелой средой, в отличие от наборов инструментов, созданных для соответствия пользовательскому выбору рабочих процессов, - но с тех пор я стал совершенно удобно с ним].
Стив Стритинг из проекта Ogre 3D (9/28/2009) опубликовал запись в блоге по этой теме, где он делает отличную и даже переданную сравнение из Git, Mercurial и Bazaar.
В конце концов он находит сильные и слабые стороны со всеми тремя и без явного победителя. С положительной стороны он дает отличный стол, который поможет вам решить, с кем идти.
Его короткое чтение, и я очень рекомендую его.
InfoQ имеет хорошее сравнение.
Что здесь видят люди как относительные сильные и слабые стороны Git, Mercurial и Bazaar?
На мой взгляд Git сила - это ее чистый базовый дизайн и очень богатый набор функций. Кроме того, я считаю, что это лучшая поддержка многопоточных хранилищ и управление рабочими процессами с большой нагрузкой. Он очень быстрый и имеет небольшой размер репозитория.
В нем есть некоторые функции, которые полезны, но приложите некоторые усилия для их использования. К ним относятся визуальная промежуточная постановка ara (индекс) между рабочей областью и базой данных репозитория, которая позволяет улучшить разрешение слияния в более сложных случаях, инкрементное усыновление и попадание в грязное дерево; обнаружение переименований и копий с использованием эвристики эвристики, а не отслеживание их с помощью каких-либо файлов-идентификаторов, которые хорошо работают и которые позволяют винить (аннотировать), которые могут отслеживать перемещение кода по файлам, а не только переименовывать файлы.
Один из недостатков заключается в том, что поддержка 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 к одной из этих распределенных систем управления версиями, какие факторы вы бы считали?
Одним из факторов, которые вы, возможно, захотите рассмотреть, является поддержка inetracting с SVN; Git имеет git -svn, Bazaar имеет bzr-svn, а Mercurial имеет расширение hgsubversion.
Отказ от ответственности: Я Git пользователь и небольшой вкладчик времени, а также смотрю (и участвую в) список рассылки Git. Я знаю Mercurial и Bazaar только из их документации, различных обсуждений в IRC и списках рассылки, а также сообщений в блогах и статей, сравнивающих различные системы контроля версий (некоторые из них перечислены на GitComparison на Git Wiki).
Mercurial и Bazaar очень похожи на поверхность. Оба они обеспечивают базовое распределенное управление версиями, так как в автономном коммите и объединении нескольких ветвей оба написаны на питоне и медленнее, чем 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.
Sun сделала оценку git, Mercurial и Bazaar как кандидаты на замену VCS Sun Teamware для базы кода Solaris. Мне было очень интересно.
Это большой вопрос, который сильно зависит от контекста, который заставил бы вас много времени печатать в одном из этих маленьких текстовых полей. Кроме того, все три из них кажутся существенно схожими при использовании для обычного материала, который делает большинство программистов, поэтому даже понимание различий требует некоторого достаточно эзотерического знания.
Вероятно, вы получите гораздо лучшие ответы, если сможете проанализировать эти инструменты до тех пор, пока у вас появятся более конкретные вопросы.
Базар ИМХО легче узнать, чем git. Git имеет хорошую поддержку в github.com.
Я думаю, вы должны попытаться использовать оба варианта и решить, что вам больше всего подходит.
Что здесь видят люди как относительные сильные и слабые стороны Git, Mercurial и Bazaar?
Это очень открытый вопрос, граничащий с пламенем.
Git является самым быстрым, но все три достаточно быстры. Bazaar является наиболее гибким (он имеет прозрачную поддержку чтения и записи для репозиториев SVN) и много заботится о работе пользователя. Меркуриал находится где-то посередине.
Во всех трех системах есть много фанатов. Я лично фанат Bazaar.
Рассматривая каждый из них друг с другом и с системами контроля версий, такими как SVN и Perforce, какие проблемы следует учитывать?
Первые являются распределенными системами. Последние являются централизованными системами. Кроме того, Perforce является проприетарным, а все остальные свободны как в речи.
Централизованный и децентрализованный - гораздо более важный выбор, чем любая из систем, которые вы упомянули в своей категории.
При планировании перехода от SVN к одной из этих распределенных систем управления версиями, какие факторы вы бы считали?
Во-первых, отсутствие хорошей замены TortoiseSVN. Хотя Bazaar работает над собственным вариантом черепашки, но он еще не появился, начиная с сентября 2008 года.
Затем обучение ключевых людей тому, как использование децентрализованной системы повлияет на их работу.
Наконец, интеграция с остальной частью системы, например, трекеры, система ночной сборки, автоматическая тестовая система и т.д.
Очень важная недостающая вещь на базаре - cp. Вы не можете иметь несколько файлов, имеющих одну и ту же историю, как в SVN, например, здесь и здесь. Если вы не планируете использовать cp, bzr - отличная (и очень простая в использовании) замена для svn.
Я использовал Bazaar какое-то время, которое мне очень нравилось, но это были только небольшие проекты, и даже тогда это было довольно медленно. Так легко учиться, но не супер быстро. Это очень x-платформа, хотя.
В настоящее время я использую Git, который мне очень нравится, поскольку версия 1.6 сделала его намного более похожим на другие VCS с точки зрения используемых команд.
Я думаю, что основные различия в моем опыте использования DVCS таковы:
В итоге Bzr был замечательным, когда я резал зубы на DVCS, но теперь я очень доволен Git и Github.
Системы управления распределенными версиями (DVCS) решают разные проблемы, чем централизованные VCS. Сравнение их похоже на сравнение молотков и отверток.
Централизованные системы VCS разработаны с намерением, что есть один Истинный Источник, который Благословен, и, следовательно, Хороший. Все разработчики работают (checkout) из этого источника, а затем добавляют (фиксируют) свои изменения, которые затем становятся похожими на Blessed. Единственное реальное различие между CVS, Subversion, ClearCase, Perforce, VisualSourceSafe и всеми другими CVCS - это рабочий процесс, производительность и интеграция, которые предлагает каждый продукт.
Распределенные системы VCS разработаны с намерением, чтобы один репозиторий был таким же хорошим, как и любой другой, и который сливается из одного репозитория в другой просто еще одна форма общения. Любое семантическое значение относительно того, какой репозиторий следует доверять, навязывается извне процессом, а не самим программным обеспечением.
Реальный выбор между использованием одного или другого является организационным - если ваш проект или организация хочет централизованного управления, DVCS не является стартером. Если ваши разработчики, как ожидается, будут работать по всей стране/миру, без безопасных широкополосных подключений к центральному репозиторию, то DVCS, вероятно, является вашим спасением. Если вам нужны оба, вы fsck'd.
ddaa.myopenid.com упомянул об этом попутно, но я думаю, что стоит упомянуть еще раз: Bazaar может читать и писать в удаленные репозитории SVN. Это означает, что вы можете использовать Bazaar локально как доказательство концепции, в то время как остальная часть команды все еще использует Subversion.
EDIT: Практически весь инструмент теперь имеет какой-то способ взаимодействия с SVN, но теперь у меня есть личный опыт, который git svn отлично работает очень. Я использую его в течение нескольких месяцев, с минимальными иконами.
Ваша основная проблема заключается в том, что это SCM Распределенные, и, как таковые, требуется немного изменить пользовательский настрой. Как только люди привыкнут к идее, технические детали и шаблоны использования встанут на свои места, но не стоит недооценивать это начальное препятствие, особенно в корпоративных условиях. Помните, что все проблемы - это проблемы людей.
Есть хорошее видео Линуса Торвальдса на git. Он является создателем Git, поэтому это то, что он продвигает, но в видео он объясняет, что такое распределенные СКМ и почему они лучше централизованные. Существует много сравнения Git (ртуть считается ОК) и cvs/svn/perforce. Также есть вопросы от аудитории относительно перехода на распределенный SCM.
Я нашел этот материал поучительным, и я продан для распространения SCM. Но, несмотря на усилия Линуса, мой выбор - меркурийный. Причина в том, что bitbucket.org, я нашел его лучше (более щедрым), чем github.
Мне нужно сказать здесь слово предупреждения: у Линуса довольно агрессивный стиль, я думаю, он хочет быть забавным, но я не смеялся. Кроме того, видео отлично, если вы новичок в распределенных SCM и думаете о переходе из SVN.