Одним из возможных объяснений является то, что вы можете забыть части набора изменений.
Если в наборе изменений вы объединяете файлы обложек, которые находятся за пределами извлеченного вами подкаталога, то всегда есть вероятность, что вы забудете объединить эти файлы.
Например, если у вас есть такой коммит на транке:
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
И тогда вы получаете извлечение 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
Кто-то должен помнить или замечать, что только часть набора изменений была объединена, а остальное необходимо сделать. Отсутствие слияния подкаталогов позволяет избежать этой проблемы.
Бывают случаи, когда вы действительно не хотите объединять все предыдущие коммиты, и вышеописанный сценарий - именно то, что вы намеревались сделать. В этом случае, вероятно, лучше добавить хорошее сообщение о коммите, описывающее ваши намерения.