Mercurial: специфичные для ветки изменения продолжают возвращаться после фиктивного слияния - PullRequest
5 голосов
/ 02 марта 2012

У меня есть ртутный репозиторий с двумя постоянными ветками, по умолчанию и UAT.Время от времени мы внедряем (продвигаем) новую версию нашего приложения в среду UAT, и мы делаем это путем объединения стабильной фиксации по умолчанию с веткой UAT.Иногда все исправляется в ветке UAT, и эти исправления возвращаются по умолчанию.

В ветке UAT мне нужно изменить несколько вещей для целей развертывания - строки подключения и различные параметры среды,Я попытался сделать эти изменения в ветке UAT и зафиксировать их (все как один коммит) сразу после слияния default в UAT.Затем я фиктивно слил этот коммит обратно по умолчанию - думая, что, поскольку по умолчанию теперь этот коммит содержится в будущем, исправление ошибок при слиянии UAT с дефолтом не будет пытаться повторить эти специфичные для UAT изменения.

Однаковсе пошло не так гладко, как я надеялся.Начиная с фиктивного коммита по умолчанию, я попробовал оба из следующих сценариев:

1) Make a few more commits to default and then "promote" to UAT (merge default onto UAT)
2) Make a bugfix on UAT and "backport" it to default (merge UAT onto default)

В промежутке между выполнением # 1 и # 2 я удалил все, так что оба сценария начинаются ста же точка.

То, что я вижу, это то, что в зависимости от последнего объединенного направления мне все еще нужно проверять измененные файлы после выполнения одного или другого слияния и возврата - иногда слияние пытается поместить конфигурации по умолчанию вUAT и иногда конфигурации UAT объединяются.

Если я отменю изменения конфигурации и зафиксирую слияние, то будущие слияния в том же направлении будут вести себя правильно, но как только я уйду в другом направлении, слияние снова помещает неправильные конфигурации в файлы.

Чего мне не хватает?

1 Ответ

5 голосов
/ 02 марта 2012

Я считаю, что проблема похожа на проблему в в этом вопросе : слияние не работает так, как вы думаете, оно работает. Слияние - это только вопрос сравнения состояний файлов, это , а не вопрос применения изменений из одной ветви в другую.

Ваша отправная точка - такая история:

UAT:      ... x --- y --- z
                           \
default:  ..... a --- b --- c

, где x и y содержат параметры конфигурации для UAT, а b - это фиктивное слияние без параметров конфигурации. Таким образом, файлы в b выглядят так же, как в a - они были фиктивно объединены.

Если вы сейчас внесете новое изменение в default, которое хотите повысить в UAT, вы будете работать с:

UAT:      ... x --- y 
                     \
default:  ..... a --- b --- c

Слияние между y и c. Это вырожденное слияние, общим предком которого является y. Это означает, что все изменения между b и c "выиграют" в трехстороннем слиянии. Таблица того, как объединяются фрагменты в трехстороннем объединении:

ancestor  local  other -> merge
old       old    old      old (nobody changed the hunk)
old       old    new      new (they changed the hunk)
old       new    old      new (you changed the hunk)
old       new    new      new (hunk was cherry picked onto both branches)
old       foo    bar      <!> (conflict, both changed hunk but differently)

Обратите внимание, что результат слияния не зависит от "направления" слияния: таблица симметрична относительно столбцов local и other. Здесь ancestor и local равны y, а other равны c. Таким образом, таблица становится:

ancestor  local  other -> merge
old       old    new      new (they changed the hunk)

Вы можете видеть, что результат объединения всегда содержит изменение new, которое было сделано в c.

Не важно, чтобы слияние было вырожденным. Предполагая, что у вас есть новый коммит в UAT и что этот коммит не касается строк конфигурации, вы получите то же поведение при слиянии (в любом направлении слияния симметричны).

Обычным решением этой проблемы является экстернализация строк конфигурации. Поместите их где-нибудь за пределы контроля версий - переменные среды, неверсионный файл конфигурации и т. Д. Если вы можете, то поместите файл конфигурации под контроль версий как шаблон . Затем вы создаете неверсионный файл конфигурации для ветви UAT, который включает файл конфигурации с управлением версиями. При необходимости вы переопределяете настройки в этом неверсионном файле конфигурации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...