Я бы хотел знать:
Некоторое время назад Google провел анализ Git и Mercurial. Вы можете прочитать это онлайн на
http://code.google.com/p/support/wiki/DVCSAnalysis
(согласно комментарию этот может быть связано с указанной выше неработающей ссылкой; поскольку комментарии изменчивы, я редактирую их в ответе)
Вы можете прочитать этот вопрос в stackoverflow:
Каковы относительные сильные и слабые стороны Git, Mercurial и Bazaar?
У Git и Mercurial больше общего, чем различий. Оба отличные.
Я использую Mercurial и не имею опыта работы с Git. От друзей, которые используют Git, я слышал, что к этому нужно привыкнуть, но после этого все отлично.
Поддержка Windows ... Я считаю, что для обоих есть интерфейс с графическим интерфейсом. Mercurial написан на Python, поэтому проблем нет.
Вот статья Эрика Синка о распределенных SCM:
Для сисадмин, Я считаю, что обратная совместимость, стабильность, надежность, безопасность и резервное копирование являются важными темами, когда речь идет о развертывании нового инструмента. Я могу дать вам некоторую информацию о Mercurial:
Обратная совместимость: Mercurial имеет заявленная политика об обратной совместимости. Правила гласят, что разные версии Mercurial всегда должен иметь возможность общаться друг с другом по HTTP (S) и SSH.
Это означает, что вы можете безопасно обновлять клиентов без одновременного обновления сервера. Вы также можете сделать наоборот и обновить сервер самостоятельно, но обычно это гораздо менее важно, поскольку новые функции появляются в клиентах и часто не требуют от сервера ничего.
В формат на диске иногда меняются - до сих пор у нас было 4 изменения. Когда это произойдет, старые клиенты откажутся работать с репозиторием на диске (но помните, что они все еще могут отправлять / опрашивать по сети). Новые клиенты по-прежнему могут читать / записывать старые форматы репозитория и никогда не будут автоматически обновлять существующий репозиторий до нового формата в случае, если репозиторий используется совместно со старым клиентом, например, через NFS. В общем, мы стараемся сделать обновления безболезненными.
Стабильность вывода: Это тесно связано с вышеизложенным. В рамках правила совместимости, мы также гарантируем, что вывод Mercurial будет стабильным. Это означает, что сценарии оболочки, которые вы пишете сегодня, будут работать и завтра.
Надежность: Как и в Git, наборы изменений идентифицируются криптографическим хеш-значением, которое вычисляется для каждого изменения и родительских наборов изменений. Это делает невозможным изменение любой части истории без того, чтобы ее заметили. Хэши проверяются каждый раз при извлечении файла.
Репозитории Mercurial состоят из множества файлы revlog. Они созданы, чтобы быть только добавление, что позволяет исправить некоторые формы повреждения оборудования путем простого усечения файлов. Вы всегда можете использовать hg verify в репозитории, чтобы Mercurial перепроверил, все ли в порядке.
Безопасность: Когда репозитории размещаются с использованием SSH, применяются все обычные правила контроля доступа - Mercurial не делает ничего особенного. Так что, если я могу войти в систему и прочитать файлы в вашем репозитории, я также смогу сделать клон. Если у меня также есть доступ на запись, я могу отправить его в репозиторий. Таким образом, управлять этим легко: просто настройте группу и убедитесь, что новые файлы доступны для записи для членов группы.
При хостинге с HTTP (S), это интерфейсный веб-сервер, который выполняет аутентификацию. Мы предоставляем CGI (с вариантами FastCGI, WSGI и ISAPI), который взаимодействует с репозиторием, но скрипт не выполняет аутентификацию. Это означает, что Mercurial легко интегрировать с существующими настройками: если вы уже используете Active Directory для аутентификации пользователей, значит, у вас все готово для использования AD с Mercurial. Видеть этот вопрос для получения дополнительной информации об AD и Mercurial.
Наконец, вместо использования hgweb CGI-скрипт, который мы предоставляем, вы можете использовать что-то вроде RhodeCode. Это обсуждается далее в этом вопросе.
Резервное копирование: Благодаря дизайну «только добавление» вы можете почти просто скопировать «живой» репозиторий, чтобы сделать резервную копию. Однако может случиться так, что таким образом вы получите слишком много данных, поскольку программа резервного копирования может скопировать «журнал изменений» до того, как скопирует «манифест», тогда как Mercurial записывает манифест до того, как записывает журнал изменений. Журнал изменений ссылается на манифест, поэтому резервная копия останется без ссылки в манифесте. Бег hg verify обнаружит это и hg recover может откатить незавершенную транзакцию.
В правильный путь делать резервные копии - это использовать hg clone. Это гарантирует, что будет скопирован согласованный моментальный снимок, даже если люди загружают данные в репозиторий во время выполнения резервного копирования. Поскольку вы можете клонировать по сети, вы можете легко отправить данные на удаленный компьютер для безопасного хранения.
Во-первых, любой из них будет огромным шагом вперед по сравнению со старыми системами - это действительно неплохой вариант.
Git немного сложнее в использовании, но он заметно быстрее и, возможно, мощнее.
Mercurial удобнее и - благодаря TortoiseHg - намного проще использовать в Windows.
В любом случае у вас есть возможность выбрать отличный хостинг (GitHub, Bitbucket, в конечном итоге Google Code), множество руководств и инструментов для миграции из других систем. Если вам нужны пользователи Windows, я бы порекомендовал Mercurial - в противном случае, вероятно, имеет смысл попробовать оба и посмотреть, какой из них вы предпочитаете. Я считаю, что Mercurial более удобен, но Git не так уж и сильно отстает и имеет несколько ужасно крутых функций (например, rebase -i).
мне нравиться Распределенные системы контроля версий: Git против Mercurial против SVN:
представляет собой серию инструментов, подобных unix, и содержит несколько слоев, таких как сантехника и porcelin, где mercurial - это скорее единый инструмент ala svn.
Я также обнаружил, что mecurial лучше работает с окнами, когда я начал изучать оба. Честно говоря, теперь git для окон довольно стабилен.
какая разница между git и mercurial?
Существует множество подробных исследований DVCS (см. Ссылки в ответах выше). Мне понравился этот недавний блог: http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ и вполне согласен с этим. Главный плюс git сегодня (начало 2010 г.) - это, наверное, github! :-)
каковы плюсы и минусы их использования?
Если у вас нет очень специфических требований, я бы сказал, что в 99% случаев оба очень хорошо делают то, что вам нужно.
Я слышал, что поддержка Windows в Git была плохой (т.е. требуется Cygwin, которого нет у большинства разработчиков Windows), но после просмотра демонстрации TortoiseGit я сказал бы, что это больше не так.
Также я слышал, что вы можете легко стереть файлы / каталоги в Git, а не в Mercurial, но я только что обнаружил это с помощью convert --filemap это тоже легко! Также расширения в оболочке или Python могут быть очень мощными (для создания команд и т. Д.), А расширение Queue позволяет очищать историю путем перебазирования, как в Git.
Таким образом, различия имеют тенденцию уменьшаться: взгляните на оба и выберите, какой из них хорош. Например, если вы уже знакомы с Subversion, с Mercurial будет проще справиться, поскольку аналогичные команды соответствуют больше, чем в Git.
Насколько хорошо Windows поддерживает оба инструмента?
См. Выше.
Надеюсь, это поможет.
Привет,
Кристоф.
Обнаружен распределенный SCM в GNOME -> http://live.gnome.org/DistributedSCM
Одна из главных побед Git - это Github и то, как он объединяет хостинг исходного кода с социальной сетью, чтобы изменить культуру вашего программного проекта.
Хотя другие dcvss, вероятно, сравнимы технически, github кажется мне настоящим шагом вперед в культурном плане.
Для необъективного сравнения см. Почему Git лучше X