In Subversion, come dovrei impostare una nuova versione principale della mia applicazione?

Ho trovato un'ottima guida a questa situazione :

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. 

Quello che vuoi fare è creare rami . È come sembra un ramo nell'albero dei sorgenti, tipicamente una copia della tua fonte quando la pubblichi. Dovresti impegnarti in questo ramo per gli aggiornamenti critici e creare l'aggiornamento da questo ramo.

Ciò a cui ti stai impegnando in questo momento sarebbe il trunk e inserirai la versione 4 del codice. Se vengono apportate modifiche sostanziali alla versione 3 e si desidera averlo nella versione 4, si farebbe un unione dal ramo (v3) al trunk (v4) per portare le modifiche su al tronco.

Puoi anche guardare i tag , che sono come diramazioni ma collegano a una singola versione, in genere l'ultima revisione di una versione (o la prima).

Dipende.

Puoi mantenere la versione 4 nel bagagliaio e continuare a sviluppare su V4. La versione 3 sarebbe un ramo, che aggiorneresti secondo necessità. Il vantaggio di questo approccio è che se in V3 è stato rilevato un problema critico, anche in V4, è possibile eseguire una semplice unione sui file tra i rami.

L'altra opzione è creare un repository completamente nuovo per V4. Questo ti darà un nuovo inizio. Lo svantaggio è che la cronologia delle modifiche viene ripristinata e non sarà possibile unire i file tramite Subversion. Dovrai utilizzare un programma come Beyond Compare per unire le modifiche.

Personalmente mi attenersi al primo approccio. Crea un ramo V3 e mantieni il codice e gli aggiornamenti in questo ramo. Il nuovo codice V4 può essere sviluppato nel bagagliaio.

Quello che stai chiedendo è la strategia di branch (e fusione) da utilizzare. Quindi prendi il posto di karthik t e prendilo come ricetta.

Per alcuni sottofondi, leggi le seguenti risorse:

• SVN Red Book per il layout del repository (singolo vs . repository multi project)
• Modelli di diramazione nel tuo contesto, utilizzerai un ramo di rilascio per versione principale
• Modelli di gestione della configurazione software la teoria di base utilizzata in Subversion (e in tutti gli altri sistemi CM). Vedi lì i modelli , in particolare la linea di rilascio lì.