Подтвердить что ты не робот

Когда действительно нужен вариант реинтеграции?

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

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

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

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

В сообщение в блоге, Марк Пиппард пишет:

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

svn merge url://[email protected] url://feature-branch .

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

совпадает с

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

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