Jak w Subversion powinienem skonfigurować nową główną wersję mojej aplikacji?

Zaraz rozpocznę pracę nad nową wersją (wersja 4) mojej aplikacji komercyjnej. Używam Subversion.

W oparciu o twoje doświadczenia, błędy i sukcesy, jak poleciłbyś skonfigurować nową wersję w Subversion?

Oto kilka informacji: Zamierzam nadal publikować krytyczne aktualizacje w wersji 3 przez jakiś czas po wydaniu wersji 4. Cały rozwój nowych funkcji będzie jednak dotyczył wyłącznie wersji 4.

W przypadku, gdy jest to istotne: jestem solistą w zakresie tego produktu i prawdopodobnie tak pozostanie.

EDYCJA: Mam świadomość tagów i gałęzi SVN. Chyba potrzebuję optymalnej strategii używania tagów i gałęzi w mojej sytuacji.

Co chcesz zrobić, to utworzyć Oddziały . To brzmi jak gałąź drzewa źródłowego, zwykle kopia źródła po zwolnieniu. Zobaczysz w tej gałęzi aktualizacje krytyczne i zbudujesz aktualizację z tej gałęzi.

To, do czego się teraz zobowiązujesz trunk, to kodowanie tam wersji 4. Jeśli jakieś ważne zmiany zostaną zatwierdzone do wersji 3, a chcesz je mieć w wersji 4, wykonasz scalenie z gałęzi (v3) do linii głównej (v4), aby przenieść zmiany do linii głównej.

Możesz także spojrzeć na tagi , które są jak gałęzie, ale prowadzą do pojedynczej wersji, zazwyczaj ostatniej wersji wersji (lub pierwszej).

To zależy.

Możesz zachować wersję 4 w bagażniku i kontynuować rozwój na V4. Wersja 3 byłaby gałęzią, którą aktualizowałbyś w razie potrzeby. Zaletą tego podejścia jest to, że jeśli krytyczny problem zostanie wykryty w wersji V3, również w wersji V4, można wykonać proste scalenie plików w gałęziach.

Inną opcją jest utworzenie i całkowicie nowego repozytorium dla V4. To da ci nowy początek. Minusem jest to, że historia zmian została zresetowana i nie będzie można scalać plików przez Subversion. Będziesz musiał użyć programu, takiego jak Beyond Compare, aby scalić zmiany.

Osobiście trzymałbym się pierwszego podejścia. Utwórz gałąź V3 i utrzymuj kod oraz aktualizacje w tej gałęzi. Nowy kod V4 można opracować w bagażniku.

Znalazłem doskonały przewodnik po tej sytuacji :

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. 

Pytasz o strategię rozgałęzienia (i scalenia). Więc weź stanowisko karthik t i weź to jako przepis.

Aby zapoznać się z tłem, przeczytaj następujące zasoby:

• SVN Red Book dla układu repozytorium (repozytoria jedno- lub wielo-projektowe)
• Wzorce gałęzi w twoim kontekście, będziesz używać gałęzi wydania dla każdej głównej wersji
• Oprogramowanie do zarządzania konfiguracją wzorców stanowi podstawową teorię stosowaną w Subversion (i we wszystkich innych systemach CM). Zobacz tam wzory , szczególnie tam linię wypuszczenia.