Perforce: Как интегрировать в несколько филиалов?

Question

У меня есть следующая ситуация ветвей в репозитории Perforce: есть магистраль «ствол» и две ветки релиза «1.0» и «1.1».Ветвь «клиент» с изменениями, специфичными для клиента, была отделена от ветки 1.0.Теперь заказчик хочет перейти на версию 1.1.Как я могу объединить ветку 1.1 в ветку клиента?Изменения, характерные для клиента, должны оставаться «сверху» 1.1.

Вот диаграмма для одного затронутого файла:

1.1                      -(1)---(2)---(3)
                        /           \     \
                       /             \     \
trunk   100--(101)-(102)--103---104---105---106---107
           \
            \
1.0          ---1-----2--...
                 \
                  \
customer           ---1-----2----*3*

Текущая версия файла, на который я смотрю, - версия 3на ветви клиента.

Если бы я решил объединить филиал «1.1» с целевым «клиентом», я бы ожидал, что общий предок обоих найден (версия 100 на главной линии), и все изменения оттуда ведут ккончики ветви 1.1 объединяются (те, что указаны в скобках).

Вместо этого Perforce предлагает только объединить ревизии с 1 по 3 ветви 1.1, что завершается неудачно, поскольку в ней пропускаются необходимые изменения, которые произошли в магистрали ранее.

Как я могу убедить Perforce сделать это, не просматривая каждый файл вручную и не выбирая ревизии для слияния?Может быть, стратегия ветвления не подходит?Что еще мне делать?

Answer 1

Когда вы пытаетесь интегрировать ревизию 3 из вашей ветви 1.1, Perforce только скажет вам, что она интегрирует изменения в этой конкретной ветке - но ревизия 1 уже содержит ревизии ствола 101 и 102. При объединении Perforce идентифицирует ревизию ствола 100 как общий предок для разрешения конфликтов.

По моему опыту, интеграция, которую вы пытаетесь сделать, должна просто работать. Вы видите, что в интегрированном источнике отсутствуют изменения (которые не могут быть объяснены неправильным разрешением конфликтов), или вы просто смотрите на вывод p4 interchanges?

Answer 2

Я настоятельно рекомендую попытаться объединить изменения клиента с транком.Это продолжит быть кошмаром обслуживания, когда через несколько месяцев клиент захочет обновить до 2.0 + свои пользовательские изменения.

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

Answer 3

Чтобы упростить интеграцию, я бы создал определенные ветви trunk_to_custer и 1.1_to_customer, а затем выполнил:

cd customer-workspace
p4 integ -b trunk_to_customer @change-number-at-which-1.1-was-branched
p4 resolve

возможно промежуточную отправку здесь, а затем

p4 integ -b 1.1_to_customer 
p4 resolve
p4 submit