Может ли Subversion правильно обрабатывать слияния в обоих направлениях (ствол <-> ветка)?

Question

Насколько я понимаю, наиболее распространенный (и рекомендуемый) способ обработки ветвлений и слияний в Subversion:

• создание ветки как копии ствола
• делает деструктивныйразработка на ветке и регулярная разработка на стволе
• При этом регулярно объединяйте изменения транк -> ветка, чтобы избежать слишком сильного расхождения ветки.С отслеживанием слиянием (svn:mergeinfo) я могу просто запустить svn merge ^/trunk, и SVN автоматически извлечет все необъединенные изменения из ствола.
• Как только работа над веткой будет завершена, объедините все обратно (в стволе:svn merge --reintegrate ^/branch/foo), затем сбросьте ветвь.

(описано, например, в книге SVN, глава Основное объединение ).

Теперь моя проблема: пока это работаетхорошо для «функциональных веток», иногда также нужны «ветки релиза», которые представляют доставку / готовность к отправке версий.

С ветвями релиза, по моему опыту, слияние должно происходить в обоих направления:

• исправления ошибок из ветки выпуска должны быть объединены в ствол (ветвь -> ствол)
• , но иногда исправление ошибки из ствола (или даже новая функция) считаетсякритический для версии выпуска (или обновления к выпуску), и поэтому должен быть объединен магистралью -> ветка

Я не нашел ничего твердого о том, как SVN и svn:mergeinfo будут обращаться с этим.Могу ли я выполнять слияние в обоих направлениях («двунаправленное слияние»), и при этом svn может отслеживать объединенные ревизии?

Есть ли подводные камни?На что обращать особое внимание?

Answer 1

На самом деле слияние в обоих направлениях в SVN часто вызывает гораздо больше боли (по сравнению с мерзавцем).Проблема заключается в том, что если вы объединяете магистраль с веткой, а затем пытаетесь объединить изменения в ветке обратно с магистралью, SVN попытается объединить изменения из магистрали, которые были снова объединены в ветку, что вызовет много ненужных конфликтов.Чтобы обойти эту проблему, вы можете «зафиксировать» только фиксацию (и), где вы объединили транк в ветвь, прежде чем объединить ветку в транк.См. Расширенное слияние - блокировка изменений в книге SVN для общего подхода (но пример, который они предоставляют, не для этого конкретного случая использования).

Пример:

1. Предположим, что ваше объединение транка с веткой создало два коммита r3857 и r3858 (я вижу, что часто при использовании NetBeans сначала создаются каталоги, а затем файлы).
2. Затем вы сделали несколько дополнительных исправлений для этого.ветвь релиза.

3. Теперь вы хотите объединить его обратно в транк.Прежде чем сделать это, сделайте следующее в вашей директории транка:

   svn merge "^ / project / branch / release-0.1" -r3857: 3858 - только для записи

4. После этого сливаемся с веткой release-0.1 как обычно.Это приведет к уменьшению числа конфликтов по сравнению с попыткой прямого слияния.

5. Перед фиксацией я иногда отменяю некоторые из внесенных изменений (в частности, SVN может по некоторым причинам вводить svnmerginfo на уровне файла, когдаразрешены конфликты деревьев).

Answer 2

Могу ли я выполнить слияние в обоих направлениях ("двунаправленное слияние"), и при этом svn будет отслеживать объединенные ревизии?

Да, вы можете объединять отдельные функции (путем объединения определенных ревизий), и SVN будет отслеживать это.