Как правильно обрабатывать повторяющиеся слияния ветки SVN?

Question

Здесь у нас есть SVN-репозиторий со стволом и веткой для разработки в новой версии.

Сейчас ветка готова к выпуску, поэтому я решил реинтегрировать ветку обратно в ствол. Очевидно, были некоторые конфликты. Включая довольно много конфликтов дерева из файлов, которые были удалены в стволе.

Я достаточно счастливо разрешил все конфликты и совершил сундук.

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

Когда я открываю график ревизий, он показывает ствол и точку, в которой ветвь была отделена, но не показывает слияние. Должно ли это?

Сервер: WinServer2003 (R2sp2), VisualSVNServer (1.7.2). Клиент: WindowsXP (sp3), я использовал TortoiseSVN (1.6.5) для всего этого, но у меня также установлен клиент командной строки.

Я выполняю слияние, проверяя, что у меня есть ствол в актуальном состоянии, и используя TortoiseSVN для слияния, и выбираю «Реинтегрировать ветку», когда отображается диалоговое окно параметров. Я установил глубину слияния на «Рабочая копия»

Я неправильно рассматриваю этот сценарий? Должен ли я делать что-то по-другому?

(Возможно, у нас неправильная компоновка репозитория. Мы разветвились от ствола, внесли все изменения для нового выпуска в ветке, теперь мы должны выпустить слияние ответвления обратно в ствол. Возможно, это неправильный подход, я читал о некоторых людях, которые делают это наоборот, вносят все изменения в ствол и делают ветку только тогда, когда вы почти готовы к выпуску и ветвь становится поддерживаемой версией выпуска)

Answer 1

С конца этой главы книги SVN следующее:

В Subversion 1.5 после выполнения слияния --reintegrate из ветви в магистраль ветвь больше не может использоваться для дальнейшей работы. Он не способен правильно поглощать новые изменения в багажнике и не может быть должным образом реинтегрирован в багажник снова. По этой причине, если вы хотите продолжить работу над веткой функций, мы рекомендуем удалить ее, а затем заново создать из ствола

Answer 2

Теперь фактически возможно повторное двунаправленное слияние

Слово предостережения. Этот ответ объясняет, как это должно быть сделано, но если вы пропустите какой-либо шаг, вы пожалеете. Например, слияние --reintegrate должно быть совершенно тривиальным (все различия уже разрешены в ветке), так как иначе вы будете молча пропускать получение изменений, которые вы сделали на шаге слияния --reintegrate, когда продолжите работать в своей ветке. Альтернативой является вместо этого удаление и повторное создание ветви каждый раз после --reintegrate.

---

По крайней мере, в версии 1.6 svn и выше вы можете выполнять повторное двунаправленное слияние. Вы можете объединить ветвь 'main' с дочерней веткой столько раз, сколько захотите, просто с помощью svn merge, но каждый раз, когда вы сливаете ветку обратно в main, вы должны задать опцию

- реинтегрировать , как указано в других ответах.

То, что вы также должны сделать, это сообщить своей ветке, что вы ее интегрировали на втором шаге вручную (с проверкой и обновлением этой ветки) с помощью команды

svn merge --record-only -c 391 ^/calc/trunk

391 здесь представляет номер коммита слияния из коммита ветки --reintegrate, который вы только что сделали в calc / trunk.

Если вы пропустите это, оно может все еще работать, или вам может потребоваться повторно разрешить конфликты слияния, которые вы уже разрешили при следующем слиянии. После шага только для записи ваши ветки готовы к дальнейшей работе или объединению. Это глупо (особенно если вы избалованы Git, как я, где все просто работает), но если вы делаете это в соответствии с этим ритуалом, это работает, и обе ветви всегда открыты для новых коммитов.

---

Все это задокументировано в книге SVN под реинтеграция дважды

Это объединение использует синтаксис объединения вишни, который был представлен в разделе под названием «Cherrypicking». Продолжая с бегом пример из раздела «Реинтеграция филиала», где ревизия X была ревизией 391:

$ cd my-calc-branch $ svn update Updating '.': Updated to revision
393. $ svn merge --record-only -c 391 ^/calc/trunk
--- Recording mergeinfo for merge of r391 into '.':  U   . $ svn commit -m "Block revision 391 from being merged into my-calc-branch."
 Sending        .

 Committed revision 394.

Теперь ваша ветка готова впитывать изменения из ствола снова. После очередной синхронизации вашей ветви с внешней линией вы можете даже повторно интегрировать ветку во второй раз. При необходимости вы можете выполнить еще одно слияние только для записи, чтобы сохранить ветвь. Сполосните и повторите.

Answer 3

В этой ситуации я не буду сливать код из ветви в транк, пока вы не завершите разработку.

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

Мой ответ делает несколько предположений, включая:

• У вас есть живой ствол и разработчик ветви
• У вас есть только один концерт версия (то есть не сохраняя наследство версии)

Надеюсь, это поможет.