Subversion è stato sviluppato come successore di CVS con l'obiettivo di correggerne i problemi e ampliarne le possibilità.

I sorgenti vengono depositati su un archivio centralizzato (repository) accessibile da locale e via rete ( tramite i protocolli http/https, svnserve, svnserve con tunnel ssh ).

Il repository di SVN è simile ad una porzione di file-system con directory, file, subdirectory ecc. Oltre ai file e la struttura SVN ne memorizza anche le variazioni nel tempo. Ogni variazione viene identificata con un numero di revisione.

Tutte le modifiche al progetto vanno fatte sulla propria copia lavoro (detta working copy).
Le modifiche al repository sono atomiche: se le transazioni non vanno tutte a buon fine il repository non viene modificato

L'approccio di svn sulle modifiche ai sorgenti da parte di più persone contemporaneamente è di non bloccare l'utilizzo delle risorse ma di lasciarle modificare e, in seguito, di fondere le modifiche (ove possibile in modo automatico).

Due modifiche effettuate sullo stesso file si definiscono "conflitti".

Se le modifiche riguardano punti diversi del sorgente (in caso di file di testo) subversion è in grado di fonderle in modo automatico. Se sono nello stesso punto del codice vanno risolte da un programmatore.

E' possibile bloccare una risorsa. Ad esempio in caso di modifiche su file binari sarebbe impossibile risolvere il conflitto in modo automatico.

Un po' di terminologia

trunk (tronco)

ramo di sviluppo principale  

branches (rami)

 rami di sviluppo secondari

tags

 ramo di sviluppo creato per un rilascio (da non modificare ulteriormente)

 working copy

 copia dei sorgenti in locale

 head

 ultima revisione del repository

 base

ultima versione scaricata dal repository (dall'ultimo update) 

Ciclo di lavoro normale

1. Si recupera il sorgente con svn checkout
2. Si fanno le modifiche
3. Quando le modifiche sono complete si controlla il repository svn status/log/diff ed eventualmente ci si prepara alla soluzione di un conflitto
4. Si aggiorna la propria working copy con le modifiche "committate" dagli altri e si risolvono i conflitti
5. Si "committano" le modifiche con svn commit (con il commit è implicito anche un update della propria BASE)
6. Si torna al punto 2

Operazioni comuni

Questa vuole essere solo una panoramica. Per una guida dettagliata del funzionamento e del client a riga di comando vi raccomando la documentazione ufficiale su http://svnbook.red-bean.com/.
 

svn import

 primo import dei sorgenti nel repository

 svn checkout

viene scaricato un ramo dal repository. La directory corrente diventa la working copy (nella directory nascosta .svn vengono scaricate le informazioni relative al repository e una copia dei sorgenti che, d'ora in avanti sarà la nostra base copy)  

svn update

aggiorna la nostra working copy (e la versione BASE) con il repository. Eventuali conflitti vengono risolti automaticamente o segnalati 

 svn commit

 le nostre modifiche vengono inviate al repository. L'operazione fallisce se la HEAD revision non è uguale alla BASE. Viene anche richiesta una descrizione delle modifiche che è buona norma scrivere.

 svn lock/unlock

 serve per bloccare/sbloccare un sorgente (per esempio un binario sul quale è necessario lavorare in una persona alla volta)

 svn resolved

quando avviene un conflitto tra le nostre modifiche e la HEAD vengono creati tre file supplementari x.mine (la mia modifica), x.revisionebase (x nella revisione del mio ultimo update) x.revisionehead (nella revisione del repository). A questo punto la questione va sistemata a mano:

• se voglio buttare via la mia modifica faccio svn revert

• se voglio utilizzare la versione del repository, dopo aver modificato a mano il file faccio svn resolved

In tutti e due i casi i files temporanei vengono cancellati  

svn revert

 Ritorna alla revisione BASE 

 svn diff

 Mostra la differenza tra due revisioni (di default tra quella locale e la BASE)

 svn log

 mostra gli ultimi log

svn status

 Mostra lo stato della working copy rispetto alla revisione BASE (se sono stati modificati, aggiunti o cancellati)
Con il flag -u mostra le modifiche rispetto alla HEAD

svn add

aggiunge un file o una directory al controllo di versione 

svn remove 

rimuove un file o una directory dal controllo di versione

svn move

muove un file o una directory   

svn copy

 utilizzato per creare branch e tag  

svn merge

fonde le modifiche tra diversi branch 

I branch ed i tag

L'utilizzo del comando svn copy ci consente di creare più versioni del nostro sorgente. Vediamo quali sono i casi d'uso più frequenti:

release branch

Si crea un ramo per gestire un rilascio. Su questo ramo verranno poi effettuate tutte le correzioni (non verranno però implementate nuove funzionalità). Eventuali correzioni dovrebbero poi essere riportate su altri rami di sviluppo utilizzando svn merge

feature branch

Si crea un ramo per sviluppare nuove funzionalità, per fare correzioni o rifattorizzazioni di una certa importanza. Una volta finita l'attività si importano le modifiche dove è opportuno (svn merge)

tag

Si crea un ramo in occasione di un rilascio. Questo Ramo viene conservato così com'è e non viene ulteriormente modificato. Serve a tenere lo storico dei rilasci.

Installazione

Su Ubuntu e Debian si può installare il client a riga di comando utilizzando:

sudo apt-get install subversion