Коммиты и слияния в подкаталогах SVN считаются вредными? - PullRequest
11 голосов
/ 17 апреля 2009

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

Однако коллега указал на ссылку на объединение подкаталогов в Контроль версий с Subversion (a.k.a "Книга SVN"):

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

Вредит ли фиксация и слияние подкаталогов SVN для веток релиза?
А как насчет кратковременных ветвей функций?

Ответы [ 4 ]

14 голосов
/ 17 апреля 2009

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

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

Например, если у вас есть такой коммит на транке:

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

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

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

6 голосов
/ 20 апреля 2009

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

1 голос
/ 17 апреля 2009

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

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

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

1 голос
/ 17 апреля 2009

При фиксации не должно возникнуть проблем, но при слиянии SVN отслеживает, что есть, а что нет,

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

...