Введение

В статье рассматриваются несколько проблем (и полезных возможностей) при работе с mercurial и предлагаются варианты их решения.

Несколько проектов на одном фреймворке

Предположим, мы используем какой-то фреймворк сразу в нескольких проектах. Для этого мы, как правило, клонируем базовый репозиторий и начинаем менять в нём файлы, связанные только с нашим проектом, тестируем, коммитим, пушим — всё как обычно.
Внезапно… мы обнаруживаем, что в самом фреймворке есть баг или нам, ну просто сил нет, нужно добавить какую-то функциональность, да заодно потестировать её с текущим проектом.
При этом мы понимаем, что эти изменения должны рано или поздно попасть в репозиторий фреймворка.

Что же делать?

Самым очевидным решением является использование патчей. Написали, проверили, выбрали только файлы относящиеся к фреймворку, сделали патч, применили патч к репозиторию проекта, закоммитили и запушили куда следует, обновились в остальных проектах по мере необходимости.

А если нужно это делать постоянно?

А теперь представим ситуацию, когда мы одновременно работаем над несколькими похожими проектами, базирующимися на одном фреймворке, или пишем собственный фреймворк. Мы создадим отдельный репозиторий для разработки, в котором будем разрабатывать и тестировать обобщённые части для всех проектов. Например:

Локальный репозиторий разработки:

• core — файлы фреймворка
• shared — общие файлы для проектов
• custom — файлы необходимые для тестирования

А ещё у вас будет репозиторий-хранилище обобщённых частей (или фреймворка):

• core — файлы фреймворка
• shared — общие файлы для проектов

Папка custom в данном репозитории естественно отсутствует, иначе при любых изменениях, они будут попадать в репозитории отдельных проектов, что недопустимо.

Изменения распостраняются по такой схеме:

репозиторий разработки → репозиторий-хранилище → репозитории проектов → (патчами) репозиторий разработки

Как же такое организовать с минимумом нервов?

Во-первых, симлинки с mercurial работать не будут, и все варианты связанные с разделением файлов между рабочими копиями лучше отбросить. (хардлинки работали бы, если бы их можно было делать на директории)

Итого, нам нужно заигнорить папку «custom». В mercurial для репозитория существует два основных метода «игнорирования»:

1. Использование файла .hgignore в корне репозитория
2. Использование .hg/hgrc игнорирования

Первый способ нам не подходит, так как .hgignore помещается в репозиторий и испортит жизнь при разработке отдельных проектов.

А вот второй способ — то, что нужно:

1. Создаём файл, аналогичный .hgignore, кладём его в удобное место (например в папку .hg или вообще вне репозитория).

2. В секции [ui] файла .hg/hgrc создаём опцию:
ignore.whatever = <абсолютный путь к файлу с правилами для игнорирования>
(Кстати таких опций с разными «whatever» может быть сколько угодно)

Заключение

Конечно, можно было существенно сократить текст статьи, и ограничиться упоминанием о «втором способе игнорирования», но это статья является лишь вводной, для более серьёзного разговора о разработке такого рода проектов.

В принципе описанная модель вполе работоспособна, однако имеет и существенные недостатки, избавиться от которых мы постараемся в следующий раз, а заодно даже научимся писать плагины для mercurial.