Отрасли вендора, меркурийский стиль?

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

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

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

Ответ 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.

Ответ 2

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

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