Як слід створити нову головну версію мого додатка в програмі Subversion?

10

Я збираюся розпочати роботу над новою версією моєї комерційної заявки (версія 4). Я використовую Subversion.

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

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

На випадок, якщо це доречно: я соло розробник цього продукту, і це, швидше за все, так і залишиться.

EDIT: Я знаю теги та гілки SVN. Я думаю, що мені потрібна оптимальна стратегія використання тегів та гілок у моїй ситуації.

version-control svn

— Стів Маклеод
джерело

8

Що ви хочете зробити, це створити Відділення . Це як звучить гілка у вашому дереві-джерелі, як правило, це копія джерела, коли ви випускаєте його. Ви б взяли на себе цю галузь для критичних оновлень та створили оновлення з цієї гілки.

Що ви зараз збираєтеся зробити, це trunkта ви будете кодувати версію 4 там. Якщо будь-які основні зміни відбудуться до версії 3, і ви хочете мати її у версії 4, ви зробите злиття від гілки (v3) до магістралі (v4), щоб перенести зміни в магістраль.

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

— Картик Т
джерело

Створюючи гілку попередньої версії, ви також можете створити тег для кожного створеного оновлення / випуску. Таким чином у вас є філія, на яку потрібно взяти зобов'язання, і ви можете використовувати теги для створення будь-якого попереднього випуску, який ви зробили.

— Geerten

Теги IIRC у svn не обов'язково посилаються на одиничні версії, вони насправді ідентичні гілкам у всіх, крім намірів,

— jk.

Насправді гілки та теги однакові за реалізацією, вони по суті є копіями коду. Лише за умовою вони різняться, теги призначені для вказівки на певну редакцію, тоді як гілка повинна бути альтернативним шляхом розвитку.

— Karthik T

3

Це залежить.

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

Інший варіант - створити абсолютно новий сховище для V4. Це дасть вам новий початок. Мінусом є скидання історії змін, і ви не зможете об'єднати файли за допомогою Subversion. Вам доведеться скористатися програмою, такою як "Більше порівняння", щоб об'єднатись у змінах.

Особисто я би дотримувався першого підходу. Створіть гілку 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 і прийміть це як рецепт.

Для ознайомлення з деякими відомостями прочитайте наступні ресурси:

SVN Червона книга для макета сховища (одиночні та багатопроектні сховища)
Шаблони гілок у вашому контексті ви будете використовувати гілку випуску для основної версії
Управління конфігурацією програмного забезпечення моделює базову теорію, яка використовується в Subversion (та всіх інших системах CM). Дивіться там шаблони , особливо там випуску.

— мельбельт
джерело