Открыть список
Как стать автором
Обновить

Mercurial для параллельной работы с несколькими похожими проектами, часть 1

Системы управления версиями

Введение


В статье рассматриваются несколько проблем (и полезных возможностей) при работе с 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.
Теги:mercurialфреймворкисистемы контроля версийhgignore
Хабы: Системы управления версиями
Всего голосов 34: ↑18 и ↓16 +2
Просмотры2.2K

Похожие публикации

Frontend-разработчик с нуля
11 мая 202177 940 ₽Нетология
PR-менеджер
11 мая 202163 900 ₽Нетология
Специализация Data Science
12 мая 2021114 000 ₽SkillFactory
SMM-менеджер
13 мая 2021Цена по запросуGeekBrains

Лучшие публикации за сутки