Когда создавать новую ветку / тег с Subversion?
Мы разрабатываем проект PHP с использованием Subversion. До сих пор мы разрабатывали ствол (/ trunk) и, наконец, выпустили версию 1.0 (сначала /branch/RB-1.0, а затем мы пометили ее как /tag/REL-1.0).
Моя идея состоит в том, чтобы выпустить исправления ошибок как 1.0.x и новые функции в 1.x, оставляя выпуск новых больших версий (2.0, …) только тогда, когда у нас есть некоторые важные изменения.
Я не знаю, когда рекомендуется сделать новую ветку / тег. Только с основной версией (1.0, 2.0, …), обычными версиями (1.1, 1.2, 2.1, …) или исправлениями ошибок (1.0.x)?
Когда я хочу выпустить исправление ошибки, рекомендуется ли исправлять его на транке или RB-1.0 и объединять его с TAG-1.0 без создания новых веток / тегов? Разметка / ветвление должны занимать много места без необходимости, не так ли? Таким образом, номер версии (1.0.x) не будет отражен в Subversion, только в моем списке изменений.
Есть ли «неофициальная» рекомендация о том, когда разветвляться / тегить?
Спасибо
Решение
Вы не должны сливаться с тегом. Сделайте новый тег. Теги должны быть в основном неизменными после их создания, иначе они не имеют смысла. Вы должны быть в состоянии сказать «tag_1.0» и точно знать, что это значит, и это должно означать то же самое через 3 года.
Не беспокойся о космосе. На сервере, если вы не вносите никаких изменений при создании тега или ветви, для тега не требуется никакого дополнительного пространства (за исключением пространства, используемого для хранения имени и некоторых метаданных). В рабочей копии это займет дополнительное место, только если вы проверите все дерево репозитория — теги, ветви и все — и вам все равно не следует этого делать. Когда ты делать Внесите изменения, только место для самих изменений (две или три строки, которые фактически изменились) займет место.
Что касается направления слияния: я думаю, что обычная практика в SVN состоит в том, чтобы исправить положение в магистрали, а затем портировать это изменение для всех отраслей, которые вы активно поддерживаете. Глава книги SVN по шаблонам ветвей обсуждает этот подход. Это хорошо работает в SVN, потому что SVN может выполнять вишневые слияния так же легко (или даже проще), что и полные слияния ветвей, и в направлении слияния нет никаких реальных преимуществ.
Другие проекты, особенно при использовании других систем контроля версий, делают обратное. Например, проект Mercurial (который использует Mercurial) прививает исправления вперед из веток релиза вместо переноса изменений из ветки «по умолчанию» (эквивалент транка в SVN). Очевидно, что механизм слияния в Mercurial работает лучше, но, как я уже говорил, я не думаю, что у SVN есть какое-то явное преимущество.
Стратегия ветвления полностью зависит от вас, но я рекомендую оставить одну ветку 1.0.x и несколько тегов 1.0.1, 1.0.2 и т. Д. Может быть, ветвь снова для 1.1.x, 1.2.x и т.д.
Вы всегда можете пересмотреть свою стратегию ветвления и переименовать / удалить ветки по мере необходимости. Они всегда будут доступны в вашей истории, если вам нужно посмотреть на них снова.
Другие решения
Других решений пока нет …