Для работы с Mercurial в Windows вам нужно всего лишь ЧерепахаHG .
Вы не сможете писать свои собственные плагины для Mercurial, но похоже, что большинство разработчиков их не пишут. В любом случае я изредка пишу только скрипты для автоматизации.
Если у вас есть Visual Studio, вы можете использовать красивую плагин .
Оставим локальные репозитории, команды на бумаге и т.п.
для студентов и лабораторных работ, которых в Интернете предостаточно.
Поскольку единственное преимущество Mercurial для простых смертных — это работа в автономном режиме, этим и следует воспользоваться.
То есть создаем основной репозиторий онлайн: Mercurial на данный момент поддерживает Майкрософт И Google (потрясающе!), поэтому апологеты могут без страданий выбрать любимую корпорацию.
Но с одной оговоркой, у MS в комментариях к коммитам нет русского языка.
Я хочу прийти к соглашению прямо сейчас.
Я сторонник политики развития Microsoft не только с точки зрения инструментов, но и с точки зрения методов.
Поэтому проблемы SVN (100 человек изменили 100 строк в одном файле и посреди праздника кто-то его переименовал) ни разу не затронули мою компанию и Subversion на 90% удовлетворительна.
Над проектом работают 3-4 программиста; отдельная задача или серия задач для одного компонента решается одним программистом.
Конфликтов между верстальщиком и верстальщиком не возникает, т. к.
они редактируют разные файлы (т. к.
код сзади), а при глобальных изменениях совместный объём работ всегда смогут согласовать.
Вам просто нужно спроектировать слабые связи между компонентами.
Оставшиеся 10% до счастья (оффлайн) будут реализованы с помощью Mercurial.
Хостинг
Выбирая услуги хостинга, я остановился на Битбакет .Во-первых, он предоставляет бесплатный хостинг для небольших частных репозиториев и платный хостинг для крупных.
Это, на мой взгляд, разумный подход — пока вас мало и вы не хотите публиковать свой код, денег с вас все равно не будет, вы найдете какой-то обходной путь.
Во-вторых, он понимает, принимает и отображает русские комментарии, в отличие от Codeplex. В-третьих, код Google выглядит современнее, работает быстрее, не дает постоянного сбоя IE9 и в целом лучше спроектирован, но имеет ограничение в 2 гигабайта на репозиторий.
2 гигабайта на репозиторий — это очень много, у нас в SVN 600 мегабайт с 200 мегабайтами чистого контента.
Вряд ли мы достигнем этой планки в ближайшие пять лет. Поэтому, если у вас нет желания закрывать код и вас не пугает ограничение в 2 гигабайта, вы можете разместиться на Google; из всех трех хостингов, которые я просматривал, он самый безупречный.
Причем переезд на другой хостинг означает максимум 1 день линейного времени и потраченный час-два.
Вложенные репозитории
Это довольно интересная тема, так как в русской версии описания Mercurial и во многих местах в Интернете пишут, что вложенные репозитории невозможны, Mercurial якобы не для этого создавался.Такая возможность на самом деле появилась уже давно.
Работает корректно относительно svn:externals, но с нюансами.
Правильность заключается в том, что используемая ревизия сохраняется в субрепозитории, и эта редакция поддерживается автоматически.
Это означает, что при клонировании вы будете использовать не последнюю версию субрепозитория, а ту, с которой работает ваш основной проект. Это нюанс номер один.
Преимущество в том, что у вас всегда есть версия вложенного проекта, с которой работает ваш основной проект (даже если вы переключитесь на старую ревизию, чтобы внести исправления в предыдущую версию вашего проекта), но небольшой недостаток в том, что вложенный проект должен обновляться вручную (обновить свою ревизию).
Поддержка правильной ревизии реализована так: при коммите во вложенный репозиторий основной репозиторий автоматически переключается на используемую ревизию вложенного репозитория.
Соответственно, чтобы все увидели ваше обновление, эта кликнутая ревизия вложенного репозитория должна быть зафиксирована; он хранится в файле «.
hgsubstate».
Второй нюанс может возникнуть, когда вы хотите передать кому-то изменения из своего репозитория напрямую.
Чтобы сделать это с нюансами, нужно внести изменения во вложенный проект, закоммитить их, закоммитить изменение ревизии (эти два коммита можно объединить в один, HG позволяет) и внести изменения в основной проект и закоммитить их тоже.
Теперь перенесите изменения из своего репозитория в другие и получите сообщение «abort: неизвестная ревизия '.
'!» Это происходит по понятным причинам — новая ревизия вложенного проекта остаётся в вашем репозитории.
Третий нюанс — отвязка от основного репозитория по умолчанию вложенного проекта.
Простой вариант — зафиксировать файл с его адресом (.
hgsub) и написать туда что угодно (например, путь в вашей локальной файловой системе), но это ненаучно.
Это научно, если вы используете раздел [subpaths] в .
hgrc. Когда вы отправляете изменения в основной репозиторий основного проекта, изменения в подпроекте автоматически передаются.
Это хорошо.
Мой совет — избегайте материализации чудесных запутанных картинок, которые рисуются во всех гайдах «для новичков» (про возможность раскидывать коммиты за тридевять земель).
Воспоминание
Знакомство с распределенными системами я начал на примере Git просто потому, что время от времени встречаю упоминания о нем.Вменяемого GUI-клиента я не нашел и все в один голос утверждают, что он есть только у Mercurial и имя ему TortoiseHG. В процессе случайного упоминания в разговоре с другом выяснилось, что его голос тоже был на стороне Mercurial. И двое других тоже.
Мне очень понравилась достопримечательность по старине.
Например, я только в комментарии с минусом обнаружил, что импорт репозитория из SVN в Mercurial не требует танцев, как описано в триллионе руководств (включая боевая вики ), руководства и многое другое – hg Convert СВН .
работает прямо из коробки TortoiseHG. И это произошло не вчера, это работает уже несколько лет. Тот же ориентир на древность и сферических коней, если сравнивать с СВН.
Ох, как печально, что многонедельные бранчи без стволов сливаются, а потом сливаются с конфликтами! Ох как грустно, что мы не можем коммитить код, который не работает, потому что мы кривые разработчики, которые не делают ветвления! Но замечательный Mercurial/Git очень плавно все сольет, потому что ля-ля-ля и ветки получаются автоматически при клонировании.
Во-первых, все сравнения почему-то проводятся с версией Subversion где-то 1.2-1.4, до больших изменений в 1.5 и с 1.7 на подходе.
Во-вторых, если вы не сольетесь с веткой dev в течение нескольких недель, вы проспите изменения, не связанные со слиянием — изменятся сигнатуры методов, интерфейсы и так далее, все прекрасно сольется, но работать не будет. .
В обратную сторону те же лошадки, только версия Mercurial взята 0.9. Видите ли, вы не можете создавать вложенные репозитории.
В русском переводе всё равно написано, что Mercurial не для этого создавался.
Английская версия уже содержит ссылки на субрепозиторий , но прошло всего несколько лет, в марте 2010 появилась даже поддержка вложенной Subversion. Теги: #dscm #Mercurial #svn #subversion #Codeplex #BitBucket #Google Code #Системы контроля версий #Mercurial #atlassian
-
Об Ограничениях P2P-Трафика
19 Oct, 24
