Записывает и объединяет подкаталоги SVN, считающиеся вредоносными?

У нас есть несколько больших подпроектов внутри основного главного проекта SVN. Я выполняю и объединяю только свой подпроект при работе с нашими ветвями выпуска, главным образом потому, что он быстрее.

Однако коллега указал на это ссылку на слияние подкаталогов в Control Version с Subversion (aka "The SVN Book" ):

Для долговечных ветвей освобождения (как описано в раздел, называемый "Общие шаблоны ветвления" ), выполнять слияния только в корне ветвь, а не в подкаталоги.

К сожалению, это степень предупреждения. Связанная секция также не дает объяснений.

Является ли объединение и слияние подкаталогов SVN, вредных для ветвей выпуска?

Как насчет короткоживущих ветвей функций?

Ответ 1

Одно из возможных объяснений заключается в том, что вы можете забыть части набора изменений.

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

Например, если у вас есть фиксация, подобная этому в trunk:

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines
Changed paths:
   M /trunk/subdir1/main.c
   M /trunk/subdir2/main.c

Change some stuff

И тогда у вас есть checkout subdir1 из вашей ветки "stable", тогда вы можете объединить набор изменений r5 следующим образом:

$ svn co http://example.com/svn/branches/stable/subdir1
$ cd subdir1
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 .
--- Merging r5 into '.':
U    main.c
$ svn ci -m"Merged r5 from trunk"

Но это только сольет половину ревизии 5. Хуже того, если вы вернетесь и посмотрите на журнал, он теперь покажет это:

$ svn log -g http://example.com/svn/
...
------------------------------------------------------------------------
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines
Changed paths:
   M /trunk/subdir1/main.c
   M /trunk/subdir2/main.c
Merged via: r6

Change some stuff

Итак, похоже, что вы объединили всю фиксацию, когда на самом деле вы только слили ее. Конечно, r6 показывает, что на устойчивой ветке изменено только 1 файл.

------------------------------------------------------------------------
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line
Changed paths:
   M /branches/stable/subdir2
   M /branches/stable/subdir2/main.c

Merge revision 5 from trunk

Кто-то должен помнить или заметить, что только часть набора изменений была объединена, а остальное нужно делать. Неиспользование слияния подкаталогов позволяет избежать этой проблемы.

Бывают случаи, когда вы действительно не хотите объединять все предыдущие фиксации, и описанный выше сценарий - именно то, что вы намеревались сделать. В этом случае лучше всего добавить сообщение о хорошей фиксации, описывающее ваши намерения.

Ответ 2

Другой причиной этого может быть то, что слияние только с корнем ограничивает количество свойств svn: mergeinfo, которые будут установлены в папках/файлах вашего репозитория.

Ответ 3

У коммитов не должно быть проблемы, но в слияниях SVN отслеживается то, что есть и не сливается.

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

Ответ 4

Для версий subversion до 1.5 слияние подкаталогов, сделанных впоследствии, слияния остальной части дерева каталогов очень сложно. Если вы объединили каталог, svn просто применил все изменения, сделанные в этом каталоге, к другой ветке. Если вы уже объединили подкаталог, а затем попытались объединить основной каталог, все изменения в подкаталоге были уже в целевой ветке (поскольку вы объединили их раньше). Svn теперь не знал, что эти изменения произошли от предыдущего слияния, он просто увидел, что были вещи "на пути", когда он пытался объединить подкаталог, в результате чего возникло множество конфликтов.

Чтобы этого избежать, вам пришлось бы позаботиться только о слиянии каталогов, которые вы ранее не объединили, что усложнило весь процесс. Вы должны были точно помнить, какие изменения в каких подкаталогах вы уже объединили, и только применить оставшиеся изменения остальных каталогов/ревизий. Это может ввести в заблуждение. Слияние всей ветки делало это намного проще. Текущие версии subversion отслеживают предыдущие слияния внутри, поэтому эти проблемы можно избежать.

Задание подкаталогов не проблема. Для svn это просто нормальная глобальная ревизия репозитория. В этой ревизии будут только изменения в одном подкаталоге, но для svn это все еще новая версия всего репозитория, как и любая другая фиксация.