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

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

В книге о Subversion говорится:

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

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

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

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

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


merge branch svn svn-reintegrate
person Tor Hovland    schedule 05.11.2009    source источник

Ответы (4)


arrow_upward
10
arrow_downward

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

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

  1. у вас есть проект p1 в p1 / trunk. В проекте есть файл readme.txt с одной строкой "line1" ‹
  2. Создайте новую ветку, p1 / branch / br1
  3. Оставайся в багажнике. Добавьте строку "line2" в readme.txt и зафиксируйте ее в магистрали
  4. Переключитесь на ветку p1/branches/br1. Обновите до HEAD.
  5. Слияние из ствола в эту ветку (чтобы улавливать изменения ствола).
  6. У вас должно быть line1 и line2 в readme.txt
  7. Зафиксировать, объединить результат в ветку p1/branches/br1
  8. Переключитесь на багажник. Обновите до HEAD.
  9. Merge from p1/branches/br1 to trunk.
    1. You'll see line1, line2 and line2 in readme.txt. So, you have "line2" two times which is incorrect. SVN does not show any conflicts. So, it is very dangerous because merge performed with no errors and you are under impression that everything is fine.

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

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

person x4444    schedule 15.08.2011
comment
Я только что сделал этот тест, используя SVN 1.7.0, и не вижу, чтобы это происходило. Вместо этого я вижу, что SVN автоматически отфильтровывает наборы изменений, которые уже существуют в связанных ветвях, независимо от направления слияния (от ствола к ветви или от ветви к стволу). Изменилось ли поведение SVN в этой области так, как это не отражено в документации? - person Neutrino; 03.04.2012
comment
Я также провел ваш тест с Netbeans 7.3.1 (который должен использовать SVN 1.7), мой сервер SVN - 1.6.17, и у меня нет проблем с повторяющимися строками. - person betatester07; 27.10.2013

arrow_upward
3
arrow_downward

Никогда не нужно использовать --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, что приведет к конфликтам.

person Matt    schedule 05.11.2009
comment
Ну вот чего я не понимаю. Почему изменения, существующие как в ветви, так и в стволе, могут привести к конфликтам, если эти изменения идентичны? - person Tor Hovland; 23.12.2009
comment
@Tor, вы бы увидели конфликт, если бы вы внесли какие-либо изменения в ветку модифицированного кода. Другими словами, эти изменения больше не могут быть идентичными. Представьте, что вы добавили 5 строк в ствол, синхронизировали их с веткой, а затем изменили их на ветке. Тогда слияние покажет конфликт: 5 строк на стволе против 5 разных строк на ответвлении. Но если бы вы использовали --reintegrate, он просто заметит разницу в ветке и объединит ее без запроса. - person Zac Thompson; 20.03.2010
comment
Означает ли это, что при слиянии без реинтеграции скажите svn merge -r 1: 100 url: // feature-branch. найдет все изменения, внесенные в url: // feature-branch от версии 1 до версии 100, и применит каждое из них к. по одному. В то время как с реинтеграцией SVN просто сравнивает разницу между rev 100 и rev 1 и рассматривает эти различия как изменения, а затем применяет их к. ? - person CarmeloS; 21.06.2012

arrow_upward
0
arrow_downward

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

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

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

person RedGlyph    schedule 05.11.2009
comment
Да, я понимаю ненужное сравнение. Но не о ненужном конфликте, о котором говорится в документации. - person Tor Hovland; 23.12.2009

arrow_upward
0
arrow_downward

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

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

такой же как

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

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

person Michael Hackner    schedule 05.11.2009
comment
Хм. Я не уверен на 100%, но я думаю, что в этом вы ошибаетесь. По крайней мере, svnbook дает совсем иную картину. svnbook.red-bean. ru / nightly / en / - person Jonik; 05.11.2009
comment
@Michael: Ты действительно в этом уверен? В документации по SVN довольно ясно, что поведение отличается, вы имеете в виду, что он определяет это автоматически при указании двух URL-адресов? - person RedGlyph; 05.11.2009
comment
Это по ссылке, указанной в ОП. «Новая опция реинтеграции - это сокращенная версия слияния двух URL ... Другими словами, реинтеграция - это просто новый синтаксис плюс некоторые проверки безопасности». Прошу прощения, но у меня нет опыта работы с этой опцией. - person Michael Hackner; 05.11.2009
comment
Реинтеграция ветки (1.6). - person dbank; 24.04.2015
comment
Что гласит: Однако при объединении вашей ветки обратно в магистраль лежащая в основе математика совсем другая. Теперь ваша функциональная ветка представляет собой мешанину из дублированных изменений ствола и изменений частной ветки, поэтому нет простого непрерывного диапазона ревизий, который можно было бы скопировать. Указав параметр --reintegrate, вы просите Subversion тщательно реплицировать только те изменения, которые уникальны для вашей ветки. (Фактически, он делает это, сравнивая последнее ствольное дерево с последним деревом ветвей: в результате получается разница именно в изменении вашей ветки!) - person dbank; 24.04.2015
comment
Также применяется с версии 1.5 - person dbank; 24.04.2015