Поставщик Ветвление, Ртутный Стиль?

Question

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

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

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

Answer 1

Использование именованных веток, как вы описали, является хорошим выбором (хотя не единственный выбор ), но я бы все же предложил использовать несколько отдельных клонов в хорошо известных местах для облегчения этого процесса.Притворяясь, что 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.

Answer 2

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

V1----V2-------------V3---------V4     Vendor
 \     \              \          \
  D1----D2---D3--D4-D5-D6-D7-D8---D9   default
                  \           \    \
                   S1----------S2---S3 stable