Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится, но вроде большинство разработчиков их и не пишет. Во всяком случае я изредка пишу только скрипты для автоматизации. Если у вас Visual Studio, можно воспользоваться красивым плагином.
Локальные репозитории, команды на бумажке и прочая оставим для студентов и лабораторных работ, которых на весь интернет вагоны. Так как единственный бенефит Mercurial для простых смертных это работа в офлайне, этим и надо пользоваться. То есть, основной репозиторий создаём в онлайне: Mercurial сейчас поддерживает Microsoft и Google (вот удивительно!), поэтому апологеты могут выбрать любимую корпорацию без мучений. Но с одним нюансом, у MS не работает русский в комментариях к коммитам.
Сразу хочу договориться. Я сторонник политики разработки Microsoft не только в плане инструментов, но и в плане способов. Поэтому проблемы SVN (100 человек изменили 100 строк в одном файле и посреди этого праздника его кто-то переименовал) ни разу не коснулись моей компании и Subversion устраивает на 90%. Над проектом работает 3-4 программиста, отдельную задачу или ряд задач по одной компоненте решает один программист. Конфликтов между верстальщиком и кодером не возникает, потому что редактируют они разные файлы (потому что code behind), а для глобальных изменений совместного фронта работ всегда смогут договориться. Просто проектировать надо слабые связи между компонентами.
Вот оставшиеся 10% до счастья (офлайн) и будут реализовываться средствами Mercurial.
Выбирая из хостингов я остановился на Bitbucket. Во-первых, он предоставляет бесплатный хостинг для небольших приватных репозиториев и платный для больших. Это, на мой взгляд, грамотный подход — пока вас мало и вы не хотите публиковать свой код, денег с вас всё равно не получишь, найдёте какой-нибудь обходной путь. Во-вторых, он понимает, принимает и показывает русские комментарии, в отличие от Codeplex. В-третьих, Google code выглядит современнее, работает быстрее, не роняет постоянно IE9 и в целом грамотнее сделан, но у него лимит 2 гигабайта на репозиторий.
2 гигабайта на репозиторий это очень много, у нас в SVN 600 мегабайтов при 200 мегабайтах чистого контента. Вряд ли мы в ближайшие лет пять достингем планки. Поэтому если у вас нет желания закрывать код и не пугает ограничение в 2 гигабайта, можно хоститься в Google, из всех трёх просмотренных мною хостингов он самый вылизанный. Тем более, что переезд на другой хостинг это максимум 1 день линейного времени и час-два потраченного.
Это довольно любопытная тема, так как в русской версии описания Mercurial и во многих местах Интернета пишут, что вложенные репозитории невозможны, не для того Mercurial, якобы, делался. Эта возможность появилась на самом деле когда-то очень давно.
Работает она, относительно svn:externals, правильно, но с нюансами. Правильность заключается в том, что для вложенного репозитория хранится используемая ревизия и эта ревизия поддерживается автоматически. Это значит, что когда вы будете делать clone, у вас будет использоваться не последняя версия вложеного репозитория, а та, с которой ваш основной проект работает. Это нюанс номер один. Плюс его в том, что вы всегда имеете ту версию вложенного проекта, с которой работает ваш основной проект (даже если переключаетесь на старую ревизию для внесения исправлений в предыдущую версию своего проекта), а небольшой минус в том, что вложенный проект надо обновлять вручную (обновлять его ревизию).
Поддержка правильной ревизии реализуется так: когда вы делаете коммит во вложенный репозиторий, у основного репозитория автоматически перещёлкивается используемая ревизия вложенного репозитория. Соответственно, чтобы все увидели ваше обновление, эту перещёлкнутую ревизию вложенного репозитория надо закомиттить, она хранится в файле ".hgsubstate".
Второй нюанс может всплыть, когда вы захотите кому-то передать изменения из своего репозитория напрямую. Чтобы это сделать с нюансом, надо внести изменения во вложенный проект, закомиттить их, закомиттить изменение ревизии (эти два коммита можно объединить в один, HG позволяет) и внести изменения в основной проект и тоже их закомиттить. Теперь пуллите изменения из вашего репозитория чужим и получаете «abort: unknown revision '...'!». Происходит это по вполне понятным причинам — новая ревизия вложенного проекта осталась в вашем репозитории.
Третий нюанс это отвязка от дефолтного main-репозитория вложенного проекта. Простой вариант это исправить файл с его адресом (.hgsub) и написать туда что угодно (например, путь на своей локальной ФС), но это антинаучно. Научно получится, если использовать секцию [subpaths] в .hgrc.
Когда вы пушите изменения в main-репозиторий основного проекта, автоматически пушатся изменения и вложенного проекта. Это хорошо. Мой совет лучше избегать материализации прекрасных запутанных рисунков, которые рисуют во всех гайдах «для начинающих» (про возможность пушить коммиты через тридевять земль).
Начал ознакомление с распределёнными системами на примере Git, просто потому что эпизодически сталкиваюсь с упоминаниями о нём. Не нашёл GUI-клиента вменяемого и все в один голос утверждают, то он есть только у Mercurial, и имя его TortoiseHG. В процессе случайного упоминания в разговоре с товарищем выяснилось, что его голос тоже на стороне Mercurial. И двух других тоже.
Очень понравился ориентир на древности. Например, я только в заминусованном комментарии обнаружил, что для импорта репозитория из SVN в Mercurial не требуется плясать, как описано в триллиарде мануалов (включая боевой вики), гайдов и прочем — hg convert svn… работает прямо из коробки TortoiseHG. И это не вчера случилось, работает несколько лет.
Тот же самый ориентир на древности и сферических коней при сравнении с SVN. Ах, как это печально, что многонедельные бранчи без мерджей с транком мерджатся потом с конфликтами! Ах, как это печально, что мы не можем комиттить код, который не работает, потому что мы криворукие разработчики не делаем бранчей! А вот прекрасный Mercurial/Git смержит всё очень гладко, потому что ля-ля-ля и бранчи получаются автоматически при клонировании. Во-первых, все сравнения проводятся зачем-то с версией Subversion где-то 1.2-1.4, до больших изменений в 1.5 и при наличии на носу 1.7. Во-вторых, если несколько недель не мерджиться с dev-веткой, то проспишь изменения, которые с мерджем не связаны — поменяются сигнатуры методов, интерфейсы и так далее, смерджится всё отлично, но работать не будет.
В обратную сторону такие же кони, только версия Mercurial берётся 0.9. Нельзя, видишь ли, создавать вложенные репозитории. В русском переводе до сих пор написано, что Mercurial создавался не для этого. В английской версии уже есть ссылки на Subrepository, а всего-то прошло несколько лет, в марте 2010 даже поддержка вложенного Subversion появилась.
Локальные репозитории, команды на бумажке и прочая оставим для студентов и лабораторных работ, которых на весь интернет вагоны. Так как единственный бенефит Mercurial для простых смертных это работа в офлайне, этим и надо пользоваться. То есть, основной репозиторий создаём в онлайне: Mercurial сейчас поддерживает Microsoft и Google (вот удивительно!), поэтому апологеты могут выбрать любимую корпорацию без мучений. Но с одним нюансом, у MS не работает русский в комментариях к коммитам.
Сразу хочу договориться. Я сторонник политики разработки Microsoft не только в плане инструментов, но и в плане способов. Поэтому проблемы SVN (100 человек изменили 100 строк в одном файле и посреди этого праздника его кто-то переименовал) ни разу не коснулись моей компании и Subversion устраивает на 90%. Над проектом работает 3-4 программиста, отдельную задачу или ряд задач по одной компоненте решает один программист. Конфликтов между верстальщиком и кодером не возникает, потому что редактируют они разные файлы (потому что code behind), а для глобальных изменений совместного фронта работ всегда смогут договориться. Просто проектировать надо слабые связи между компонентами.
Вот оставшиеся 10% до счастья (офлайн) и будут реализовываться средствами Mercurial.
Хостинг
Выбирая из хостингов я остановился на Bitbucket. Во-первых, он предоставляет бесплатный хостинг для небольших приватных репозиториев и платный для больших. Это, на мой взгляд, грамотный подход — пока вас мало и вы не хотите публиковать свой код, денег с вас всё равно не получишь, найдёте какой-нибудь обходной путь. Во-вторых, он понимает, принимает и показывает русские комментарии, в отличие от Codeplex. В-третьих, Google code выглядит современнее, работает быстрее, не роняет постоянно IE9 и в целом грамотнее сделан, но у него лимит 2 гигабайта на репозиторий.
2 гигабайта на репозиторий это очень много, у нас в SVN 600 мегабайтов при 200 мегабайтах чистого контента. Вряд ли мы в ближайшие лет пять достингем планки. Поэтому если у вас нет желания закрывать код и не пугает ограничение в 2 гигабайта, можно хоститься в Google, из всех трёх просмотренных мною хостингов он самый вылизанный. Тем более, что переезд на другой хостинг это максимум 1 день линейного времени и час-два потраченного.
Вложенные репозитории
Это довольно любопытная тема, так как в русской версии описания Mercurial и во многих местах Интернета пишут, что вложенные репозитории невозможны, не для того Mercurial, якобы, делался. Эта возможность появилась на самом деле когда-то очень давно.
Работает она, относительно svn:externals, правильно, но с нюансами. Правильность заключается в том, что для вложенного репозитория хранится используемая ревизия и эта ревизия поддерживается автоматически. Это значит, что когда вы будете делать clone, у вас будет использоваться не последняя версия вложеного репозитория, а та, с которой ваш основной проект работает. Это нюанс номер один. Плюс его в том, что вы всегда имеете ту версию вложенного проекта, с которой работает ваш основной проект (даже если переключаетесь на старую ревизию для внесения исправлений в предыдущую версию своего проекта), а небольшой минус в том, что вложенный проект надо обновлять вручную (обновлять его ревизию).
Поддержка правильной ревизии реализуется так: когда вы делаете коммит во вложенный репозиторий, у основного репозитория автоматически перещёлкивается используемая ревизия вложенного репозитория. Соответственно, чтобы все увидели ваше обновление, эту перещёлкнутую ревизию вложенного репозитория надо закомиттить, она хранится в файле ".hgsubstate".
Второй нюанс может всплыть, когда вы захотите кому-то передать изменения из своего репозитория напрямую. Чтобы это сделать с нюансом, надо внести изменения во вложенный проект, закомиттить их, закомиттить изменение ревизии (эти два коммита можно объединить в один, HG позволяет) и внести изменения в основной проект и тоже их закомиттить. Теперь пуллите изменения из вашего репозитория чужим и получаете «abort: unknown revision '...'!». Происходит это по вполне понятным причинам — новая ревизия вложенного проекта осталась в вашем репозитории.
Третий нюанс это отвязка от дефолтного main-репозитория вложенного проекта. Простой вариант это исправить файл с его адресом (.hgsub) и написать туда что угодно (например, путь на своей локальной ФС), но это антинаучно. Научно получится, если использовать секцию [subpaths] в .hgrc.
Когда вы пушите изменения в main-репозиторий основного проекта, автоматически пушатся изменения и вложенного проекта. Это хорошо. Мой совет лучше избегать материализации прекрасных запутанных рисунков, которые рисуют во всех гайдах «для начинающих» (про возможность пушить коммиты через тридевять земль).
Флэшбэк
Начал ознакомление с распределёнными системами на примере Git, просто потому что эпизодически сталкиваюсь с упоминаниями о нём. Не нашёл GUI-клиента вменяемого и все в один голос утверждают, то он есть только у Mercurial, и имя его TortoiseHG. В процессе случайного упоминания в разговоре с товарищем выяснилось, что его голос тоже на стороне Mercurial. И двух других тоже.
Очень понравился ориентир на древности. Например, я только в заминусованном комментарии обнаружил, что для импорта репозитория из SVN в Mercurial не требуется плясать, как описано в триллиарде мануалов (включая боевой вики), гайдов и прочем — hg convert svn… работает прямо из коробки TortoiseHG. И это не вчера случилось, работает несколько лет.
Тот же самый ориентир на древности и сферических коней при сравнении с SVN. Ах, как это печально, что многонедельные бранчи без мерджей с транком мерджатся потом с конфликтами! Ах, как это печально, что мы не можем комиттить код, который не работает, потому что мы криворукие разработчики не делаем бранчей! А вот прекрасный Mercurial/Git смержит всё очень гладко, потому что ля-ля-ля и бранчи получаются автоматически при клонировании. Во-первых, все сравнения проводятся зачем-то с версией Subversion где-то 1.2-1.4, до больших изменений в 1.5 и при наличии на носу 1.7. Во-вторых, если несколько недель не мерджиться с dev-веткой, то проспишь изменения, которые с мерджем не связаны — поменяются сигнатуры методов, интерфейсы и так далее, смерджится всё отлично, но работать не будет.
В обратную сторону такие же кони, только версия Mercurial берётся 0.9. Нельзя, видишь ли, создавать вложенные репозитории. В русском переводе до сих пор написано, что Mercurial создавался не для этого. В английской версии уже есть ссылки на Subrepository, а всего-то прошло несколько лет, в марте 2010 даже поддержка вложенного Subversion появилась.
