Subversion nasce attorno al 2000 come alternativa a CVS, nel frattempo diventato obsoleto. Il suo intento dichiarato è risolvere i bug e i difetti intrinsechi di CVS, mantenendone però lo spirito e i concetti di base.
Rispetto a CVS, Subversion introduce:
* versionamento delle directories: con CVS il controllo di versione era applicato solo ai file, quindi le operazioni di copia e spostamento tra diverse directory non era gestito adeguatamente. Con Subversion viene tenuta traccia anche del contenuto di ogni singola directory e quindi lo spostamento di un file è a tutti gli effetti considerata una modifica, quindi rintracciabile e reversibile.
* commits atomici: una serie di modifiche viene applicata solo in blocco – se anche solo una di esse crea errori, non viene applicata nessuna delle modifiche inviate. Questo evita la creazione di versioni incomplete che dovrebbero poi essere corrette a mano.
* versionamento dei metadati: è possibile assegnare a file e directory delle proprietà personalizzate – dei veri e propri metadati – e mantenere lo storico anche delle modifiche a queste proprietà.
* astrazione dal livello di rete: l'accesso dal client al repository (cioè al deposito centralizzato dei files) può avvenire attraverso il protocollo HTTP (sfruttando un apposito modulo di Apache), attraverso un apposito server standalone (SVNServe), o direttamente attraverso il filesystem (ma solo nel caso in cui il repository sia situato sulla stessa macchina). In tutti questi casi, i comandi e le operazioni fondamentali non cambiano, così come non cambia la struttura del repository e delle copie di lavoro locali.
Nonostante nel frattempo siano nati altri strumenti, con concetti e soluzioni innovative, Subversion si sta tenendo aggiornato e sembra reggere la competizione.
Il primo è più importante concetto è quello del repository: il deposito dove risiedono i nostri dati. È possibile creare diversi repository su ogni server Subversion; vedremo come ciascuno di essi sia accessibile con un URL specifico.
Per lavorare sui file si utilizza il client SVN per creare una copia di lavoro locale. Tale copia è quella su cui vengono effettuate le vere e proprie modifiche, che poi verranno caricate sul server.
La creazione di una nuova copia di lavoro locale è detta checkout. Contrariamente ad altri sistemi di controllo di versione, in Subversion tale operazione non blocca niente sul server: semplicemente estrae i file per permetterci di cominciare a lavorare su di essi. Si possono fare quanti checkout si vogliono, anche solo per consultazione, eliminando poi la copia locale quando non ci serve più.
Il caricamento delle modifiche locali sul server è detto commit. È quando effettuiamo un commit che entra in gioco il "filtro" di Subversion, con l'obiettivo di controllare e segnalare se le nostre modifiche vadano in conflitto con altre già presenti sul repository.
Ogni commit andato a buon fine genera una nuova revisione, ovvero aumenta di 1 il numero di revisione del repository. Ogni repository parte alla revisione 0.
L'aggiornamento di una copia locale già esistente è detto update. In maniera opposta al commit, si occupa di applicare alla nostra copia di lavoro le ultime modifiche caricare sul repository.
Le operazioni di checkout, commit e update si effettuano con gli omonimi comandi.
I rami (branches) sono versioni separate del progetto, solitamente diversificate per permettere l'implementazione di aggiunte o modifiche rispetto al ramo principale, mantenendo tale ramo principale intatto.
Le etichette (tag) sono un modo per "fissare" definitivamente una revisione che ha un significato particolare, ad esempio il primo rilascio di un progetto. Per non doversi ricordare il numero di revisione, si può etichettare (appunto) la revisione con un nome specifico che risulti mnemonico per noi (es. "Versione di rilascio").
Subversion non è particolarmente schizzinoso relativamente al tipo di dati di cui si deve occupare. Altri sistemi di controllo dei sorgenti possono essere più specifici, ad esempio essere dedicati a un determinato linguaggio di programmazione e includere magari anche un debugger o un compilatore automatico; Subversion non è così.
Qualunque server Subversion può ospitare contemporaneamente sorgenti PHP e HTML, ma anche normale documentazione, guide, articoli, e perfino immagini, brani musicali, e qualsiasi altro file vi venga in mente. Potremmo utilizzarlo anche per salvare le nostre macchine virtuali.
L'unica importante distinzione è tra i file di tipo mergeable e binari. I primi sono sostanzialmente file di testo, in cui le diverse modifiche provenienti da diversi autori possono essere valutate e unite riga per riga, come spiegheremo più avanti. Gli altri file, invece, vengono considerati da Subversion come "monoblocco" e verranno sempre sostituiti interamente (stiamo parlando ad esempio di immagini o brani musicali). In questo secondo caso perdiamo la possibilità di unire le modifiche fatte da diversi utenti, ma rimane valido il controllo di versione vero e proprio, cioè la conservazione automatica e il rapido accesso alle versioni precedenti.
Detto tutto questo, non cadiamo nell'errore di considerare Subversion un semplice sistema di archiviazione e distribuzione. Il suo obiettivo principale è quello di gestire i cambiamenti nel tempo, tenendo a portata di mano una copia di ciascuna versione e dandoci la possibilità di tracciare chi e quando ha introdotto certe modifiche.
Componenti "server".
Sul server devono risiedere i moduli che garantiscono l'accesso al repository, nonché gli eseguibili di gestione. In particolare i componenti significativi sono:
* svnadmin, il programma che permette la creazione e gestione del repository;
* mod_dav_svn, il modulo per Apache che rende disponbile il repository tramite protocollo HTTP – richiede ovviamente una installazione funzionante del server httpd;
* svnserve, il server svn standalone che può – opzionalmente – essere usato al posto del modulo per Apache;
* svn, il client da linea di comando.
Tra l'utilizzo di un modulo per Apache e l'utilizzo di svnserve è consigliabile senz'altro la prima opzione, in quanto ci permette di sfruttare altre potenzialità del Web server quali l'autenticazione tramite file htpasswd e l'utilizzo di sistemi di crittografia (OpenSSL) per proteggere e limitare l'accesso al repository.
Dalla home page del progetto è possibile scaricare le versioni per tutti i principali sistemi operativi. La maggior parte delle distribuzioni Linux include inoltre Subversion nei repository ufficiali dei propri pacchetti.
Il progetto VisualSVN Server offre inoltre un pacchetto "all-in-one" che ci permette di installare su Windows tutti i componenti server necessari.
Componenti "client".
Sul client risiedono i programmi grafici o da linea di comando per accedere alle funzioni di un server Subversion. Il client da linea di comando è spiegato nel dettaglio nel manuale ufficiale di Subversion. Esistono inoltre almeno due client grafici degni di menzione.
* TortoiseSVN, il client “ufficiale” di Subversion per Windows. È gratuito e nella homepage del progetto SubVersion è elencato per primo tra i client ... e questo vorrà dire qualcosa :-)
* SmartSVN, un client multipiattaforma basato su Java, che da altrettante soddisfazioni a chi ha avuto modo di provarlo.
Questi client in particolare vengono utilizzati come estensioni del filesystem; il che significa che non lavorano come un'applicazione separata, bensì offrono i comandi come opzioni del menu contestuale (tasto destro o equivalente su altri sistemi).
I client SVN grafici utilizzano gli stessi comandi per dialogare con il server Subversion (e non potrebbe essere altrimenti); svn checkout, svn commit, e così via. In alcuni casi, tuttavia, offrono delle scorciatoie interessanti per le operazioni più comuni e/o offrono maschere di dialogo che ci evitano di dover ricordare la sintassi completa dei comandi. Inoltre, propongono una maggiore verbosità negli elenchi e nei messaggi di errore, e ci offrono opzioni aggiuntive: ad esempio la possibilità di navigare il repository da remoto.
Oltre ai client citati, esistono anche estensioni per i più noti IDE, quali Eclipse e VisualStudio. In particolare per Visual Studio esiste VisualSVN, prodotto dalla stessa compagnia che produce VisualSVN Server.
Per i fedelissimi della shell, ovviamente è possibile fare tutto da linea di comando.
Un elenco completo dei client di SubVersion è riportato nella home page del progetto stesso. Per il resto di questa guida, utilizzeremo TortoiseSVN, e gli esempi faranno riferimento a questo programma. In ogni caso, i comandi sono comuni a tutti, ed è semplice individuare i comandi equivalenti anche usando un client diverso.
Creazione di un repository.
L'operazione di creazione di un nuovo repository è molto semplice, basta digitare il comando:
svnadmin create
inserendo il percorso dove creare il repository, ad esempio
svnadmin create /var/svn/repository
Questo comando crea la cartella principale in cui verranno salvati tutti i nostri progetti.
Facciamo subito alcune importanti considerazioni sulla posizione e la nomenclatura di ogni repository.
Anzitutto, a seconda del tipo di file, un repository può crescere molto e quindi è bene prevedere lo spazio necessario.
Una buona scelta, sui sistemi UNIX, è quella di collocare il repository in /var, che oltre a rappresentare l'aderenza allo standard, è utile perchè solitamente nella stessa cartella ci sono i log di sistema nonché vari altri dati che tendono a crescere, e quindi l'amministratore esperto avrà già riservato un po' di spazio in più, e magari anche creato una partizione separata.
Inoltre, potendo creare più di un repository, è pratica comune utilizzare questa possibilità per avere un repository diverso per ogni progetto.
Nel nostro caso, volendo creare un repository specifico per ospitare i vari file HTML che contengono questa guida, il mio comando diventerà:
svnadmin create /var/svn/guidasvn Attenzione ai permessi sui file! Dopo aver creato il repository, sarà necessario dare all'utente che esegue il server Apache (sempre ipotizzando di aver scelto la pubblicazione via Apache) i permessi di lettura e scrittura su tali cartelle. Presto parleremo anche di come proteggere i nostri dati tramite autenticazione
Cancellazione di un repository.
Attenzione a non confondere la cancellazione di uno o più file e cartelle del progetto con la cancellazione dell'intero repository. Se anche il nostro progetto non ci piace più e vogliamo riscrivere tutto da zero, possiamo comunque usare gli strumenti client per cancellare tutti i file, e poi applicare le modifiche a Subversion, che – coscienziosamente – continuerà a mantenere anche le versioni precedenti. In questo modo, se ci rendiamo conto che qualcosa del vecchio progetto era da salvare, possiamo estrarre una vecchia versione del progetto, magari anche solo per recuperare pochi file.
Se però siamo davvero convinti a cancellare l'intero repository, perchè abbiamo completamente abbandonato il progetto, o l'abbiamo trasportato su un altro server o sistema di controllo di versione, o semplicemente abbiamo fatto dei test seguendo questa guida e ora vogliamo fare pulizia, possiamo cancellare tutto eliminando la cartella che contiene il repository.
Nell'esempio di prima, si tratterebbe di cancellare semplicemente la cartella guidasvn contenuta in /var/svn. Infatti tutte le informazioni di versione e di configurazione di ciascun repository sono contenute nel repository stesso.
Nota: chi si occupa di gestire dei server probabilmente lo sa, ma le cancellazioni vanno fatte sempre con cautela. È utile fare sempre prima una copia di backup; assicurarsi di cancellare solo la specifica cartella, e non tutta la cartella /var/svn e con essa tutti i repository creati. Sempre valido il consiglio di non fare le cose di fretta.Repository multipli e autenticazione.Per creare un unico host da usare per tutti i repository è possibile specificare la cartella superiore come DocumentRoot, e poi utilizzare il parametro SVNParentPath al posto di SVNPath. Procediamo con la modifica:
- Apriamo il file
/etc/apache2/sites-available/svn - Modifichiamo il parametro
DocumentRootdandogli il valore/var/svn/ - Sostituiamo la riga
SVNPath /var/svn/guidasvn
conSVNParentPath /var/svn - Salviamo e chiudiamo il file
- Ricarichiamo Apache
In questo modo diciamo ad Apache che nella cartella in questione saranno presenti diversi repository, per cui ora l'accesso a ciascuno di essi richiede che aggiungiamo all'url anche il nome del repository. Nel nostro caso utilizziamo:
http://svn.vd-devel/repos/guidasvn
Saremo in grado di visualizzare nuovamente il contenuto attuale del repository (ovvero il repository vuoto).
A questo punto della configurazione, il contenuto del repository è liberamente disponibile a chiunque abbia accesso al server Web. Possiamo comunque ridurre gli accessi grazie ad un meccanismo di autenticazione.
Autenticazione HTTP.
Non è oggetto di questa guida spiegare i dettagli tecnici dell'autenticazione HTTP implementata da Apache. È comunque possibile ricavare informazioni al riguardo sulla documentazione ufficiale.
Iniziamo invece direttamente dal il comando necessario per creare un file di autenticazione:
htpasswd -c /etc/svn-htpasswd hugo
Nei parametri da passare inseriamo il nome di un file che conterrà l'elenco di coppie username e password, e l'utente per cui sto creando o modificando la password. L'opzione -c specifica la creazione del file, quindi va usata solo per il primo utente, mentre per i successivi basterà:
Ora bisogna segnalare ad Apache che l'elenco di account da usare per gestire l'accesso al nostro sito è contenuto nel file appena creato. Per farlo modifichiamo il file del virtual host (/etc/apache2/sites-available/svn) e aggiungiamo le righe necessarie:
1
2 LoadModule dav_svn_module modules/mod_dav_svn.so
3 ServerName svn.vd-devel
4 DocumentRoot /var/svn/
5
6 DAV svn
7 SVNParentPath /var/svn
8 Require valid-user
9 AuthType Basic
10 AuthName "Inserisci i dati per l'accesso al repository"
11 AuthUserFile /etc/svn-htpasswd
12
13
Le righe dalla 8 alla 11 indicano ad Apache che bisogna essere dei valid-user (cioè bisogna autenticarsi) per accedere al sito, e forniscono i parametri per verificare l'autenticazione.
Se ricarichiamo Apache e proviamo nuovamente ad accedere via browser, appare la una mascherina intitolata "Inserisci i dati per l'accesso al repository". Immettendo la corretta combinazione di username e password – che abbiamo definito prima tramite il comando htpasswd – possiamo visualizzare il contenuto del repository, altrimenti saremo tenuti fuori.
Questo è solo il primo, più semplice livello di autenticazione e non garantisce una sicurezza elevatissima, soprattutto visto che le password vengono praticamente passate in chiaro via rete.
Esiste la possibilità di stringere le maglie, ad esempio utilizzando AuthType Digest anziché Basic, che evita appunto il passaggio delle password, o ancora meglio utilizzando un certificato SSL per criptare tutto il traffico dal client al server. Sono opzioni che riguardano competenze specifiche di Apache per cui, anche in questo caso, non approfondiremo oltre in questa guida.
fonte: Linux HTML
Screenshots.
Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog: