Когда действительно необходим вариант реинтеграции?

Question

Если вы всегда синхронизируете ветвь функции, прежде чем объединить ее обратно. Почему вы действительно должны использовать --reintegrate вариант?

Книга Subversion гласит:

Однако при слиянии вашей ветви обратно в ствол базовая математика совершенно иная. Ваша ветвь функций теперь представляет собой смесь как дублированных изменений ствола, так и изменений частной ветви, поэтому нет простого непрерывного диапазона ревизий для копирования. Указав параметр --reintegrate, вы просите Subversion тщательно реплицировать только те изменения, которые уникальны для вашей ветви. (И на самом деле, он делает это, сравнивая последнее ствол дерева с последним деревом ветвей: результирующая разница - это именно ваши изменения веток!)

Итак --reintegrate Параметр объединяет только те изменения, которые являются уникальными для функциональной ветви. Но если вы всегда синхронизируете перед объединением (что является рекомендуемой практикой, чтобы справиться с любыми конфликтами в ветви функций), то единственными изменениями между ветвями являются изменения, которые являются уникальными для ветви функций, верно? И если Subversion попытается объединить код, который уже находится в целевой ветви, он просто ничего не сделает, верно?

В своем блоге Марк Фиппард пишет:

Если мы включим эти синхронизированные ревизии, мы объединяем изменения, которые уже существуют в транке. Это приводит к ненужным и запутанным конфликтам.

Есть ли пример, когда отбрасывание реинтеграции дает мне ненужные конфликты?

Answer 1

Позвольте мне объяснить, когда --reintegrate абсолютно необходимо.

Рассмотрим следующий вариант использования.

1. у вас есть проект p1 под p1 / trunk. В проекте есть файл, readme.txtс одной строкой "line1"<
2. Создайте новую ветку, p1 / branch /br1
3. Оставайтесь в багажнике. Добавить строку "line2" в readme.txt и передать его в багажник
4. Переключиться на p1/branches/br1 ветка. Обновление до головы.
5. Слияние со ствола в эту ветку (чтобы подобрать изменения ствола).
6. У тебя должно быть line1 а также line2 в readme.txt
7. Подтвердить слияние результата с p1/branches/br1 ветка
8. Переключиться на багажник. Обновление до головы.
9. Слияние с p1/branches/br1 to trunk.
   1. Вот увидишь line1, line2 а также line2 в readme.txt, Итак, у вас есть "line2" два раза, что неверно. SVN не показывает никаких конфликтов. Так что это очень опасно, потому что слияние выполнено без ошибок и у вас сложилось впечатление, что все в порядке.

Решение здесь состоит в том, что объединение шага 9 должно быть выполнено с использованием --reintegrate вариант. Опция реинтеграции говорит SVN для сравнения br1 с багажником и применять только br1 меняется на багажник. В данном конкретном случае мы не сделали никаких изменений в br1, Результатом в магистрали должно быть две строки "line1" и "line2".

Еще одно полезное замечание. Ветка p1/branches/br1 больше не должен использоваться для разработки после шага 9. Если вы хотите продолжить разработку в филиалах, создайте новую ветку, например, p1/branches/br2, Еще одно слияние из ствола в p1/branches/br1 вызывает много конфликтов.

Answer 2

Никогда не нужно использовать --reintegrate; это удобство. Если ваше последнее слияние с trunk в feature-branch объединены все изменения, произошедшие в trunk так как вы разветвились до ревизии rev, тогда вы можете использовать следующую команду.

svn merge url://trunk@rev url://feature-branch .

Обратите внимание, что эта команда будет выполняться в корне обновленной рабочей копии trunk без каких-либо выдающихся изменений.

Позвольте мне расширить свой ответ, чтобы более прямо ответить на вопрос "Есть ли пример, когда отбрасывание реинтеграции вызывает у меня ненужные конфликты?"

Вот что подразумевается в статье: "Если мы включим эти синхронизированные ревизии, то мы объединяем изменения, которые уже существуют в транке. Это приводит к ненужным и запутанным конфликтам".

Включение синхронизированных ревизий будет выглядеть так:

svn merge -r N:HEAD url://feature-branch .

куда . это чистая рабочая копия ствола и N это ревизия, которая feature-branch был создан из trunk, Эта команда объединения объединяет все изменения, внесенные в feature-branch поскольку он был разветвленным, включая те изменения, которые были объединены с trunk после feature-branch был создан. Это означает, что изменения уже внесены в trunk будет включен в слияние выше. Вы бы сказали Subversion применить изменения к trunk что на самом деле возникла в trunk, что приводит к конфликтам.

Answer 3

Я думаю, что Mark означает, что он избегает сравнения двух файлов, которые были изменены, один для реинтеграции из ветви и соответствующий ему файл в стволе, когда оба были синхронизированы (а не просто изменены локально в соответствующей ветке).

Давайте предположим, что у нас есть trunk/a.c а также branches/dev/a.c, с trunk/a.c изменен в какой-то момент и позже интегрирован в ветку слиянием. Как вы указали, это хорошая практика, прежде чем положить все обратно в багажник.

Таким образом, следующим шагом будет слияние обратно в ствол, где a.c "разные" с обеих сторон, так как они изменились в обоих местах. Без опции будет ненужное сравнение, где --reintegrate заставит SVN увидеть изменения не только локальные.

Answer 4

Никогда не нужно использовать --reintegrate - это просто псевдоним. Если у вас есть рабочая копия trunk, затем

svn merge --reintegrate url://feature-branch workingcopy

такой же как

URL-адрес слияния svn: // URL-адрес ствола: // рабочая копия функции-ветви

Вы можете использовать тот, который вам удобнее.