В Subversion, как мне установить новую основную версию моего приложения?

10

Я собираюсь начать работу над новой версией (версией 4) моего коммерческого приложения. Я использую Subversion.

Исходя из вашего опыта, ошибок и успехов, как бы вы порекомендовали мне установить новую версию в Subversion?

Вот некоторая информация: я намерен продолжать выпуск критических обновлений в версии 3 в течение некоторого времени после выпуска версии 4. Однако все разработки новых функций будут исключительно в версии 4.

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

РЕДАКТИРОВАТЬ: Я знаю о тегах и ветвях SVN. Я думаю, что мне нужна оптимальная стратегия использования тегов и веток в моей ситуации.

version-control svn Стив Маклеод
источник

Ответы:

8

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

То, во что вы ввязываетесь прямо сейчас, было бы trunkи вы бы там кодировали версию 4. Если какие-либо серьезные изменения были внесены в версию 3, и вы хотели бы иметь ее в версии 4, вы должны выполнить слияние из ветви (v3) в транк (v4), чтобы перенести изменения в транк.

Вы также можете посмотреть на теги , которые похожи на ветки, но ссылаются на одну версию, обычно последнюю версию (или первую).

Картик Т
источник
При создании ветки предыдущей версии вы также можете создать тег для каждого создаваемого вами обновления / выпуска. Таким образом, у вас есть ветка для фиксации, и вы можете использовать теги для сборки любого предыдущего релиза, который вы сделали.
Гертен
Теги IIRC в svn не обязательно ссылаются на отдельные версии, они фактически идентичны ветвям во всем, кроме намерения
jk.
На самом деле, ветви и теги идентичны по реализации, они по сути являются копиями кода. Только условно, что они различаются, теги предназначены для указания на конкретную ревизию, в то время как ветвь должна быть альтернативным путем разработки.
Картик Т
3

Это зависит.

Вы можете оставить версию 4 в багажнике и продолжить разработку на V4. Версия 3 будет веткой, которую вы будете обновлять по мере необходимости. Преимущество этого подхода состоит в том, что если в V3 обнаружена критическая проблема, которая также есть в V4, вы можете выполнить простое объединение файлов в филиалах.

Другой вариант - создать совершенно новый репозиторий для V4. Это даст вам новый старт. Недостатком является то, что история изменений сбрасывается, и вы не сможете объединять файлы через Subversion. Вам придется использовать такую ​​программу, как Beyond Compare, чтобы объединить изменения.

Лично я бы придерживался первого подхода. Создайте ветку V3 и сохраните код и обновления в этой ветке. Новый код V4 может быть разработан в багажнике.

Чак Конвей
источник
2

Я нашел отличное руководство по этой ситуации :

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too.
Стив Маклеод
источник
0

То, о чем вы спрашиваете, - это использовать стратегию ветвления (и слияния). Так что возьми пост karthik t и прими это как рецепт.

Для некоторого фона прочитайте следующие ресурсы:

mliebelt
источник