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

10

Sto per iniziare a lavorare su una nuova versione (versione 4) della mia applicazione commerciale. Uso Subversion.

In base alle tue esperienze, errori e successi, come consiglieresti di impostare la nuova versione in Subversion?

Ecco alcune informazioni: intendo continuare a rilasciare aggiornamenti critici nella versione 3 per qualche tempo dopo il rilascio della versione 4. Tuttavia, lo sviluppo di nuove funzionalità sarà esclusivamente nella versione 4.

Nel caso sia rilevante: sono uno sviluppatore solista su questo prodotto e probabilmente rimarrà tale.

EDIT: sono a conoscenza dei tag e dei rami di SVN. Immagino che ciò di cui ho bisogno sia una strategia ottimale per l'utilizzo di tag e rami nella mia situazione.

version-control svn

— Steve McLeod
fonte

8

Quello che vuoi fare è creare Branches . È come sembra un ramo nell'albero dei sorgenti, in genere una copia della fonte quando lo rilasci. Dovresti impegnarti in questo ramo per gli aggiornamenti critici e creare l'aggiornamento da questo ramo.

Quello a cui ti stai impegnando in questo momento sarebbe il trunke tu codificheresti la versione 4 lì dentro. Se vengono apportate modifiche importanti alla versione 3 e si desidera averlo nella versione 4, si eseguirà un'unione dal ramo (v3) al trunk (v4) per portare le modifiche al trunk.

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

— Karthik T
fonte

Mentre crei un ramo della versione precedente, puoi anche creare un tag per ogni aggiornamento / rilascio che crei. In questo modo hai un ramo a cui impegnarti e puoi usare i tag per creare qualsiasi versione precedente che hai fatto.

— Geerten,

I tag IIRC in svn non si collegano necessariamente a singole versioni, in realtà sono identici ai rami in tutto tranne che a intension

— jk.

In realtà, i rami e i tag sono identici nell'implementazione, sono essenzialmente copie del codice. È solo per convenzione che differiscono, i tag intendono puntare a una revisione particolare, mentre il ramo dovrebbe essere un percorso di sviluppo alternativo.

— Karthik T

3

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 si riscontra un problema critico in V3 che è anche in V4, è possibile eseguire una semplice unione sui file tra i rami.

L'altra opzione è quella di creare un repository completamente nuovo per V4. Questo ti darà un nuovo inizio. Il rovescio della medaglia è 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 atterrei al primo approccio. Creare un ramo V3 e conservare il codice e gli aggiornamenti in questo ramo. Il nuovo codice V4 può essere sviluppato nel trunk.

— Chuck Conway
fonte

2

Ho trovato un'eccellente 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.

— Steve McLeod
fonte

0

Quello che stai chiedendo è la strategia di succursale (e unione) da usare. Quindi prendi il post di karthik t e prendilo come una ricetta.

Per alcuni retroscena, leggi le seguenti risorse:

SVN Red Book per il layout del repository (repository singolo o multiprogetto)
Branch Branchs nel tuo contesto, utilizzerai un branch di rilascio per la versione principale
Software Configuration Management Patterns 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ì.

— mliebelt
fonte