Введение
В статье рассматриваются несколько проблем (и полезных возможностей) при работе с mercurial и предлагаются варианты их решения.
Несколько проектов на одном фреймворке
Предположим, мы используем какой-то фреймворк сразу в нескольких проектах. Для этого мы, как правило, клонируем базовый репозиторий и начинаем менять в нём файлы, связанные только с нашим проектом, тестируем, коммитим, пушим — всё как обычно.
Внезапно… мы обнаруживаем, что в самом фреймворке есть баг или нам, ну просто сил нет, нужно добавить какую-то функциональность, да заодно потестировать её с текущим проектом.
При этом мы понимаем, что эти изменения должны рано или поздно попасть в репозиторий фреймворка.
Что же делать?
Самым очевидным решением является использование патчей. Написали, проверили, выбрали только файлы относящиеся к фреймворку, сделали патч, применили патч к репозиторию проекта, закоммитили и запушили куда следует, обновились в остальных проектах по мере необходимости.
А если нужно это делать постоянно?
А теперь представим ситуацию, когда мы одновременно работаем над несколькими похожими проектами, базирующимися на одном фреймворке, или пишем собственный фреймворк. Мы создадим отдельный репозиторий для разработки, в котором будем разрабатывать и тестировать обобщённые части для всех проектов. Например:
Локальный репозиторий разработки:
- core — файлы фреймворка
- shared — общие файлы для проектов
- custom — файлы необходимые для тестирования
А ещё у вас будет репозиторий-хранилище обобщённых частей (или фреймворка):
- core — файлы фреймворка
- shared — общие файлы для проектов
Папка custom в данном репозитории естественно отсутствует, иначе при любых изменениях, они будут попадать в репозитории отдельных проектов, что недопустимо.
Изменения распостраняются по такой схеме:
репозиторий разработки → репозиторий-хранилище → репозитории проектов → (патчами) репозиторий разработки
Как же такое организовать с минимумом нервов?
Во-первых, симлинки с mercurial работать не будут, и все варианты связанные с разделением файлов между рабочими копиями лучше отбросить. (хардлинки работали бы, если бы их можно было делать на директории)
Итого, нам нужно заигнорить папку «custom». В mercurial для репозитория существует два основных метода «игнорирования»:
- Использование файла .hgignore в корне репозитория
- Использование .hg/hgrc игнорирования
Первый способ нам не подходит, так как .hgignore помещается в репозиторий и испортит жизнь при разработке отдельных проектов.
А вот второй способ — то, что нужно:
1. Создаём файл, аналогичный .hgignore, кладём его в удобное место (например в папку .hg или вообще вне репозитория).
2. В секции [ui] файла .hg/hgrc создаём опцию:
ignore.whatever = <абсолютный путь к файлу с правилами для игнорирования>
(Кстати таких опций с разными «whatever» может быть сколько угодно)
Заключение
Конечно, можно было существенно сократить текст статьи, и ограничиться упоминанием о «втором способе игнорирования», но это статья является лишь вводной, для более серьёзного разговора о разработке такого рода проектов.
В принципе описанная модель вполе работоспособна, однако имеет и существенные недостатки, избавиться от которых мы постараемся в следующий раз, а заодно даже научимся писать плагины для mercurial.
