#encoding koi8-r #extends phd_site #implements respond #attr $Title = 'git vs Mercurial' #attr $Copyright = 2012 ## #def body_rst git против Mercurial ==================== .. class:: head Опыт работы с Mercurial у меня длительный -- больше трёх лет -- но малоинтенсивный. Я попал в сравнительно небольшой стабильный проект, в котором я стал единственным программистом. Большого развития проект не требовал, эксперименты делать не приходилось, так что весь набор команд, который я использовал -- commit, tag и изредка pull в бэкапный репозиторий. .. class:: head С git же у меня совершенно другая история. После завершения предыдущего проекта меня бросили на укрепление здоровенного сложного проекта, в котором человек 5 активных программистов в основном репозитории, плюс наши и сторонние библиотеки. Вот ещё года не прошло, а я освоил git куда лучше, чем hg. И теперь, оглядываясь назад, я считаю, что это правильные способы использования их обоих. Mercurial -- он слегка попроще, чем git, зато с более отполированной оболочкой. В идеологии Mercurial история изменений священна, и расширения для переписывания истории выглядят чужеродно. База данных устроена соответственно -- как набор append-only файлов. hg help -- это короткая напоминалка, а не документация. Mercurial позволяет несколько видов ветвлений --клоны, именованные бранчи, анонимные бранчи (для именования которых есть расширение bookmarks). Именованные ветки имеют недостаток -- они занимают имя в глобальном пространстве имён, любой клон копирует эти имена. Способа удаления ветки нет, разве что сделать клон, перечислив при клонировании все ветви, кроме удаляемой. Что неудобно. Зато hg написан на Питоне, что удобно питоновским программистам для написания расширений и хуков. Моё резюме такое: Mercurial -- это для не очень больших не слишком интенсивных проектов. .. class:: head Много достоинств git спрятаны от поверхностного взгляда. База данных. Линус разрабатывал её как универсальную файловую систему, адресуемую содержимым. БД хранит коммиты, теги и деревья (связки между коммитами). Гибкое устройство БД позволяет делать с ней что угодно, т.е. переписывание истории в git -- вполне естественный, чуть ли не встроенный процесс. Недостатком БД является накопление мусора (коммитов, оставшихся без ссылок), необходимость регулярной упаковки БД для ускорения доступа, и сборки мусора. Упаковка делается командой git repack, сборка мусора плюс упаковка -- git gc. Mercurial поддерживает свою БД автоматически, но она в hg и проще устроена. Поверх БД в git лежит низкоуровневая программная оболочка -- libgit и программы git plumbing. Уровнем выше -- git porcelain, программы и скрипты, которые можно использовать, в т.ч. и в собственных скриптах. На самом высоком уровне -- большой набор традиционных команд типа git-commit, git-branch и т.д., в т.ч. сама высокоуровневая оболочка git и графический интерфейс gitk. git help -- более подробный, чем в hg, к тому же у него два варианта -- текст и html, так что при желании help можно читать в браузере. Ветки в git более легковесные, они легко создаются, переименовываются и удаляются (сборщик мусора потом приберёт отвалившееся). В clone/pull/push ветки не попадают автоматически, каждую нужную ветвь надо явно назвать. При этом ветки находятся в пространстве имён только одного репозитория, сделав pull из другого репозитория, даже назвав ветвь, получаешь названную ветвь в отдельном пространстве имён. Есть возможность создать в своём репозитории ветвь, связав её с такой удалённой веткой. Аналогом в hg, хотя и несколько более упрощённым, будут анонимные ветви, поименованные с помощью закладок. Лёгкость создания и удаления ветвей в git позволяет быстро проводить эксперименты. Отбежал в сторонку, покрутил фишку в руках, быстренько прибрал за собой -- и свободен. .. class:: head В результате этих наблюдений я думаю, что git -- более перспективная штука, чем Mercurial. Как я уже говорил_, в настоящий момент hg и git функционально полностью эквивалентны, хотя я уже вижу, что Mercurial несколько меньше подходит для больших, интенсивно развивающихся проектов. Но когда для git будут написаны различные оболочки и графические интерфейсы, или вовсе придуманы различные нестандартные способы использования -- он обгонит hg далеко и надолго, возможно, навсегда. .. _говорил: hg_git.html .. class:: head *Upd*. Немного статистики:: $ dpkg -l '*hg*' | wc -l 36 $ dpkg -l '*mercurial*' | wc -l 10 $ dpkg -l '*git*' | wc -l 69 И это с учётом того, что в поиск по hg попал sshguard и много тому подобного лишнего. В поиск по git лишнего тоже попало, но не так много. *Upd2*. Ещё немного статистики: http://upsilon.cc/~zack/stuff/vcs-usage/ #end def $phd_site.respond(self)