Вендор Ветвление, Ртутный Стиль?

Сцена: купленное веб-приложение с регулярными обновлениями от поставщика. Затем мы тщательно настраиваем внешний вид, а иногда добавляем нашу собственную функциональность или исправляем ошибку до того, как продавец доберется до нее. Для контроля версий мы использовали Subversion, следуя их модели Vendor Branch, каждый раз, когда получали новую версию. Это дает дополнительное преимущество, так как у нас есть контролируемая версия, ванильная копия их системы.

Проблема: мы хотели бы перейти на Mercurial и, скорее всего, будем придерживаться стабильного / стандартного шаблона ветвления. Mercurial имеет смысл, если бы мы получили только один выпуск от нашего поставщика и начали его разработку оттуда. Но по какой-то причине у меня возникают проблемы, когда я думаю о том, как обращаться с будущими выпусками от поставщика.

Призыв: любая помощь с "ветвлением поставщика" в стиле Mercurial будет принята с благодарностью.

Источник

2 ответа

Решение

Использование именованных веток, как вы описали, является хорошим выбором (хотя и не единственным), но я бы все же предложил использовать несколько отдельных клонов в хорошо известных местах для облегчения этого процесса. Делая вид, что http://host/hg/ это hgweb (ранее hgwebdir) для вашей установки (хотя ssh:// тоже отлично работает, что угодно), у вас будет что-то вроде этого:

  • http://host/hg/vendor
  • http://host/hg/custom

Два отдельных репозитория, в которых данные передаются от поставщика к заказу, но не в другом направлении Названная ветвь default будет единственным в vendor И в custom вы бы оба default а также stable,

Когда вы получаете новый код от поставщика, вы распаковываете его в рабочий каталог vendor репо, а затем запустить:

hg addremove
hg commit -m 'new drop from vendor, version number x.x.x'

Ваша история в этом vendor Репо будет линейным, и в нем никогда не будет ничего, что вы написали.

Теперь в вашем местном клоне custom репо вы бы сделали:

hg update default     # update to the latest head in your default branch
hg pull http://host/hg/vendor   # bring in the new changes from vendor as a new head
hg merge tip          # merge _your_ most recent default cset with their new drop

И затем вы выполняете работу по слиянию ваших локальных шансов по умолчанию с их новым удалением кода. Когда вы довольны слиянием (тестирование пройдено и т. Д.), Вы возвращаетесь из своего локального клона обратно в http://host/hg/custom,

Этот процесс может повторяться по мере необходимости, обеспечивает хорошее разделение между вашей историей и историей, и позволяет каждому в вашей команде не отвечать за принятие новых выпадений кода от поставщиков, чтобы заниматься только нормальным default/stable настройка в одном репо, http://host/hg/custom,

Источник

Я бы использовал ветку вендора как дополнительную ветку по умолчанию + стабильные. В конце это будет выглядеть примерно так:

V1----V2-------------V3---------V4     Vendor
 \     \              \          \
  D1----D2---D3--D4-D5-D6-D7-D8---D9   default
                  \           \    \
                   S1----------S2---S3 stable
Источник
Другие вопросы по тегам