Introduzione al controllo di versione

QUANTE volte scrivendo il codice di un qualsiasi sorgente vi siete accorti che il lavoro delle ultime due ore era del tutto sbagliato e avreste voluto tornare indietro al codice di due ore prima, oppure non riuscite a capire per quale modifica il codice non funziona più. Bè se vi siete trovati in questa situazione allora avete bisogno del controllo di versione.

Il controllo di versione, o version control (VCS), è un software per la gestione di versioni differenti di un qualsiasi tipo di informazione (disegni, sorgenti, libri). In particolare nel campo della programmazione si occupa di tenere traccia di tutte le modifiche apportate ai file sorgente di un progetto software, questo può benissimo essere un sorgente scritto in C oppure un applicazione web o più semplicemente un plugin di WordPress, ma potrebbe benissimo essere un libro che stiamo scrivendo.

Il controllo di versione tenendo traccia di ogni modifica apportata consente di ritornare facilmente a vecchie versioni, di ricordarci ogni modifica che abbiamo apportato e di lavorare su versioni differenti dello stesso sorgente.

Solitamente il controllo di versione si utilizza su architetture di tipo client server. Ovvero c’è un server che contiene i repository (la raccolta di tutti i dati) e i client da remoto ci accedono per scaricare la copia locale su cui lavorare. Una volta finite le modifiche si “ricarica” la copia locale nel repository in modo da archiviare e volendo anche condividere le modifiche. Il modo più veloce per accedere ai repository è tramite linea di comando ma per chi non ci si trovasse bene esistono anche delle interfacce grafiche.

Un altra importantissima caratteristica è il supporto alla stesura collaborativa tra più persone dello stesso progetto, con il controllo di versione è possibile condividere gli stessi file sorgente sempre aggiornati e visualizzare chi ha modificato cosa. Alcuni software semplicemente impediscono a più persone contemporaneamente di modificare lo stesso file (lock) altri invece offrono strumenti (come il merge) per consentire l’unione di modfiche contemporanee dello stesso file e di risolvere eventuali conflitti che ne scaturiscono.

Dopo quest’introduzione vi presento un non esaustivo decisamente “alla mano” glossario e qualche risorsa per Subversione il software di controllo di versione più diffuso. In realtà questo post mi serviva per introdurre il prossimo che pubblicherò, nel quale confronterò tre VCS ovvero Git, Mercurial e Bazaar.

Glossario

Alcuni termini da conoscere che accomunano più o meno tutti i software di controllo di versione.
Commit: operazione con cui si carica la working copy nel repository
Repository: archivio dove risiede il progetto e tutte le revisioni, attraverso il quale è possibile risalire a revisioni precedenti, solitamente ci si accede da remoto.
Working Copy: è la copia locale del progetto a cui stiamo lavorando
Revision: è un numero che identifica ogni commit
Merge: è l’unione di modifiche concorrenti dello stesso file
Checkout: azione che si compie per scaricare in locale la working copy
Tagging: dare un preciso nome di versione ad una revisione
Branching: duplicare i dati sotto controllo di versione per portare avanti sviluppi paralleli dello stesso progetto
Log: registrazione cronologica di ogni operazione effettuata
Diff: comando per visualizzare le differenze tra due diverse revisioni

Subversion

Comando: svn
Nota storica: Naturale sucessore di CVS è nato nel 2000 ed è rilasciato sotto la stessa licenza di Apache. E’ forse il software per il controllo di versione più diffuso. Dal 2009 è stato incluso nei progetti dell’Apache software foundation.
Progetti che lo utilizzano: KDE, GCC, PHP
Applicazione grafica: TortoiseSVN (Windows) SvnX (MAC) kdesvn (KDE)
Sito ufficiale: subversion.apache.org
Guida: libro “Controllo di versione con Subversion” (quasi interamente tradotto in italiano)
Cheat sheet: Subversion-cheat-sheet.png
Hosting gratutito per progetti open source: code.google.com/hosting, projectlocker.com, freepository.com, sourceforge.net, BerliOS
Altro: molto comodo Subclipse il plugin per integrare SVN in Eclipse.

Brevissimo Subversion tutorial

HO da poco caricato nel repository di wordpress.org la nuova versione aggiornata del mio plugin FlickrRSS RU ed essendo passato un po di tempo dall’ultima volta che l’ho fatto, ci ho impiegato qualche minuto per ricordarmi bene la procedura. Ecco quindi una brevissima guida per ricordami bene come si fa la prossima volta. In realtà questa guida va benissimo per qualsiasi progetto utilizzi subversion come software di controllo di versione.

Per prima cosa se non avete già una copia in locale sincronizzata (o non vi ricordate dove sia) bisogna scaricare il repository, spostatevi nella cartella dove lo volete scaricare e create una cartella in cui metterlo:

$ mkdir flickrrssRU

poi lanciate il comando per copiarlo tutto in locale

$ svn checkout http://svn.wp-plugins.org/flickrrss-ru flickrrssRU 

l’output sarà qualcosa di simile a questo:

A    flickrrssRU/trunk
A    flickrrssRU/trunk/flickrrssRU.php
A    flickrrssRU/trunk/screenshot-2.png
A    flickrrssRU/trunk/flickrrssRU-settingspage.php
A    flickrrssRU/trunk/readme.txt
A    flickrrssRU/trunk/screenshot-1.png
A    flickrrssRU/branches
A    flickrrssRU/tags

spostatevi nella cartella della copia locale, per esempio nel mio caso

$ cd /var/www/flickrrssRU 

e controllate che sia aggiornata all’ultima versione sul repository. Nel caso ci siano più persone che lavorano allo stesso plugin (più in generale allo stesso progetto) potrebbe essere che non lo sia, ovviamente qualcuno potrebbe aver modificato il progetto. Se invece l’avete appena scaricato sarà sicuramente aggiornato.

$ svn update

se state per rilasciare una nuova versione del progetto, e non dovete solo apportare delle modifiche minori, prima di tutto bisogna taggare la versione attuale in modo da renderla fissa nel tempo. Per esempio nel caso la nuova versione aggiunga delle nuove funzioni, a qualcuno potrebbero non interessare, o un altro caso molto più comune è per la compatibilità, se nella versione che state andando a rilasciare sono state fatte delle grosse modifiche potebbe non funzionare più con alcune applicazioni, pertanto qualcuno in questi casi vorrà comunque continuare ad utilizzare le vesioni precedenti.

Per fare questo copiamo il contenuto della cartella trunk (quindi l’attuale versione del progetto da taggare) in una sottocartella di tags nominata con la versione che stiamo andando ad “archiviare”

$ svn copy trunk tags/0.2 

ora possiamo aggiornare e modificare i file che si trovano nella cartella trunk con i file della nuova versione. Ricordatevi se state rilasciando una nuova versione di un plugin per WP di modificare i numeri di versione anche all’interno del file readme. Una volta che avete inserito nella cartella trunk i file aggiornati se avete aggiunto dei nuovi file che prima non c’erano dovete lanciare questo comando:

$ svn add trunk/nome_nuovo_file

oppure se dovete eliminare dei file:

$ svn delete trunk/nome_file_da_rimuovere

Ora per finire bisogna caricare tutte le modifiche effettuate ovvero effettuare il COMMIT. Con esso tutte le modifiche effettuate sui dati vengono memorizzate. Il -m serve per poter personalizzare il messaggio di log ovvero il testo messo tra virgolette, è un aiuto quando si va a vedere il log del repository per ricordarsi le modifiche che sono state effettuate ad ogni commit.

$ svn commit -m "tagging version 0.2"

Comandi Subversion

Vi lascio la lista dei principali comandi di subversion (rigorosamente da lanciare preceduti dal comando svn) con una brevissima descrizione, per vedere bene come funzionano basta lanciare il comando:

$ svn help nome-del-comando

i comandi scritti tra parentesi tonde sono gli equivalenti meno user-friendly ma più veloci

add Aggiunge file e directory al controllo di versione
blame (praise, annotate, ann) Restituisce il contenuto dei file specificato con varie informazioni
cat Restituisce il contenuto dei file specificato
checkout (co) Copia in locale una working copy
commit (ci) Trasmette le modifiche della copia locale al repository
copy (cp) Copia file o cartelle da un sorgente ad una destinazione
delete (del, remove, rm) Rimuove file o cartelle dal controllo di versione
diff (di) Mostra le differenze tra due revisioni
export Crea una copia senza metterla sotto controllo di versione
help (?, h) Descrive l’uso di un comando
import Esegue il commit di un percorso non sotto il controllo di versione
info Mostra varie informazioni
list (ls) Elenca il contenuto della directory nel repository
lock Blocca cartelle e file nel repository dalla modifica da parte di altri utenti
log Mostra i log di un file o dell’intero repository
merge unisce varie modifiche dello stesso file
mergeinfo mostra le info relative al merge
mkdir crea una cartella nel repository
move (mv, rename, ren) sposta o rinomina file e cartelle
status (stat, st) Mostra lo stato attuale tra la copia locale e il repository
unlock Sblocca i percorsi o i file bloccati con lock
update (up) Aggiorna la copia locale con quella del repository

Ed ecco un “cheat sheet” per subversion: