Sistemi di gestione delle revisioni

Gli SCM sono tool che rappresentano il pane quotidiano degli sviluppatori. Nel corso degli anni sono stati sviluppati parecchi di tali sistemi, con pregi e difetti vari per ognuno di essi. Esistono anche alcuni SCM commerciali come Perforce o Bitkeeper (per anni usato per lo sviluppo del kernel di Linux).

In realtà alcuni SCM possono essere utilizzati anche per mantenere revisioni di cose che non sono affatto codice sorgente. Per esempio alcuni system administrator mantengono intere configurazioni di /etc sotto SCM per vari server. E' questo un modo di mantenere contemporaneamente un backup e una storia delle modifiche su sistemi di produzione. Alcuni utenti mettono su SCM anche l'intera home: si tratta di applicazioni limite, ma in certi contesti interessanti.

Gli SCM si classificano minimalmente in:

• distribuiti
• centralizzati

Per la verità si considerano SCM anche programmi storici come SCCS (proprietario) o il suo clone GNU RCS, che sono oggi largamente obsoleti e rappresentano gli antenati dei moderni SCM. Chi scrive ha usato nel 1990 per l'ultima volta SCCS e questo rende largamente idea della sua obsolescenza - oltre all'età di chi scrive Non di meno in alcuni contesti un programma come RCS può ancora essere utile.

Lo scopo di questo articolo è presentare una breve e limitata carrellata delle caratteristiche generali di alcuni noti SCM e un sommario dei concetti comuni alla maggior parte di essi.

Nozioni fondamentali

Alcuni termini e concetti sono comuni a tutti gli SCM e quindi vediamone una breve carrellata per allineare la terminologia.

Un SCM - per definizione - deve tenere traccia delle revisioni di ciascun file, associando un numero di revisione o versione ad ognuno di essi o all'insieme di tutti i file del tree dei sorgenti. Questo viene fatto ad ogni nuovo snapshot o commit dei sorgenti.

Parimenti deve essere in grado di presentare le differenze (in termini di unified diff tipicamente) tra versioni successive o due qualsiasi revisioni nella storia del tree dei sorgenti; deve associare un log descrittivo (editabile) ad ogni snapshot registrato da uno sviluppatore, per ciascun file o per l'intero albero (tipicamente si associa un solo log all'intero snapshot); deve consentire di etichettare uno snapshot nella storia (una release o tag) in modo da consentire un veloce recupero dell'albero relativo senza dover ricordare un numero di revisione non intuitivo (ammesso che sia solo uno!); deve consentire la gestione di alberi di revisione derivati a qualsiasi livello della storia e in qualsiasi momento. Si parla in questi casi di branch o fork.

La prima operazione di copia in locale da repository remoto per iniziare l'editing di una qualsiasi revisione è chiamata checkout oppure clone.

Un SCM che si rispetti deve consentire di lavorare a lock (che impedisce le modifiche ad altri di uno o più file o di un intero tree fino all'unlock da parte dello sviluppatore) o a merge (che consente l'editing contemporaneo a tutti, ma richiede la ricongiunzione delle modifiche ad ogni snapshot) a seconda delle esigenze. Lo stile di lavoro a merge è quello tipicamente impiegato nel 90% del tempo. Ovviamente il locking non ha senso nel caso di SCM distribuiti.

CVS

E' il decano degli SCM, derivato da RCS e pensato per essere compatibile con il suo antenato. Molti lo considerano semplicemente un RCS dopato. Lo sviluppo è quasi fermo e chi ha messo il naso nel codice lo considera un gran guazzabuglio. Non di meno è tutt'oggi il primo sistema a cui si pensa quando si parla di SCM, e quello di riferimento per implementare un SCM degno: deve fare almeno tutto quello che fa CVS e non averne i difetti.

E' un SCM a repository centralizzato, il che vuol dire che si è costretti a fare continue connessioni in rete locale o Internet per lavorarci. Localmente le directory di lavoro CVS mantengono praticamente solo l'indirizzo del repository e la lista dei file sotto controllo.

Rispetto a SCM più moderni ha parecchi difetti: ogni file ha una sua propria revisione, quindi non esiste un vero concetto di revisione globale, o di patchset che dir si voglia. A questo si aggiuge che se malauguratamente dovesse venire interrotta la connessione durante un commit, il commit rimane fatto per metà, non c'e' modo di fare un rollback delle operazioni compiute fino all'interruzione per ricominciare in modo coerente. Il sistema di branching, tagging e moduli è peraltro abbastanza confuso e incoraggia i developer a creare una eccezionale confusione, rendendo ingestibile tree di certe dimensioni.

Cambiare nome o spostare/cancellare directory e file è una operazione per cuori forti. Il CVS non mantiene traccia della storia passata di un file nel momento in cui questo cambia nome. Il risultato è che la gestione di sorgenti frequentemente mutevoli nella struttura del tree diventa un incubo ed è preferibile creare un modulo completamente nuovo per ogni revisione maggiore.

Il sistema ritiene ogni file un sorgente (quindi un testo) e vi applica sopra alcuni automatismi (per es. l'espansione delle macro $X$) adatti ai sorgenti, ma non certo a una immagine per esempio: bisogna quindi pre-marcare ogni file binario come tale per evitare danni irrimediabili al contenuto di tali file al primo commit. Il guaio è che spesso ci si dimentica di considerare binari alcuni file che invece dovrebbero esserlo per CVS, per esempio i file di patch, e quindi il danno è assicurato...

In definitiva CVS per quanto ancora usatissimo, è considerato ormai in obsolescenza. Chi ha familiarità con CVS immancabilmente vede Subversion come suo naturale sostituto. In alcuni particolari contesti inoltre, laddove sia conveniente mantenere numeri di revisione diversi per file diversi (es. alberi di documentazione cui partecipano molti revisori, ognuno con responsabilità di pochi file) è tuttora conveniente.

Subversion (SVN)

E' un sistema a repository centralizzato, parzialmente usabile anche senza connessione per alcune operazioni grazie all'uso di una cache locale. Proprio la presenza della local cache rende più ingombranti i tree di checkout rispetto a CVS. Mantiene una sintassi simile a CVS per la gestione di file e directory, ma risolve alcuni dei punti deboli di CVS:

• Mantiene traccia di tutte le modifiche anche su directory e metadata, oltre che sui file. In questo modo è possibile tenere traccia di ogni operazione (spostamento, cancellazione o ridenominazione) di ogni file o directory.
• I commit sono realmente atomici, quindi se l'operazione viene interrotta per un qualche motivo nessuna modifica viene applicata al repository.
• Offre un server stand-alone (svnserve) con possibilità di gestire utenti e relativa autenticazione e di un modulo per l'interfacciamento con Apache. E' possibile utilizzare connessioni sicure con ssh in maniera semplice grazie allo schema svn+ssh:// che non ha bisogno di lanciare nessun demone, in quanto l'esecuzione dei comandi avviene in maniera trasparente in una sessione ssh creata ad-hoc.
• Gestione efficiente dei file binari, grazie ad agoritmi di diffing binari. Il repository cresce in dimensioni proporzionalmente alle modifiche effettuate.
• Tutti i file sono considerati binari se il propset degli stessi non indica diversamente (che mi pare un default decisamente più sano).

Il branching e tagging sono semplici operazioni di copia sul database di backend da un tree ad un altro, per cui risultano di fatto efficienti e molto lineari. Subversion usa un paio di engine alternativi per la gestione dei metadati lato repository, Berkely DB e FSFS. Il backend più tradizionale è BDB, che è però soggetto a rischio di data corruption in caso di problemi hardware o software sul repository centrale. E' quindi molto opportuno effettuare backup periodici con il tool di amministrazione. L'uso di FSFS in alternativa è apprezzabile perchè evita tale problema, infatti dalla versione 1.2 il backend FSFS è diventato quello di default.

Il formato del repository è totalmente libero, per cui occorre lavorare con un po' d'ordine e definire una sana policy per evitare proliferazioni di tree alternativi e in definitiva il caos. La policy ufficiale prevede la divisione del repository in project (corrispondenti ai moduli di CVS) e per ogni project la creazione di tre aree denominate branches, tags e trunk. La trunk in particolare mantiene il ramo principale di sviluppo, le altre directory i rami di fork e le singole release frozen. Niente impedisce di introdurre ulteriori directory 'standard' (es. experimental per i branch sperimentali).

Esiste una gran quantità di tool che semplificano l'uso di SVN (http://scm.tigris.org/), tra cui:

• Rapid SVN: interfaccia grafica a SVN disponibile per ambienti Linux, Windows e Mac OS/X
• cvs2svn: serve a convertire un repository CVS in SVN.
• websvn: interfaccia web a SVN.
• trac: integra la gestione di repository SVN e offre un sistema completo di gestione dei progetti composto da un Wiki e da un gestore dei bug.

Una carenza fondamentale di subversion è la mancanza di un sistema di tracking delle modifiche di branch per-developer. Su progetti particolarmente grossi, se si lavora su un proprio branch e di tanto in tanto si effettua il merge da repository centrale delle modifiche fatte da altri, non si è più in grado di distinguere le proprie modifiche da quelle di merge: la nuova revisione le comprende tutte. A lungo andare i merge continui fanno perdere di vista quali sono le proprie modifiche e quali quelle di altri, diventa quindi improponibile gestire un albero custom dal quale si possa facilmente estrarre i propri soli changeset. Subversion è quindi inusabile in certi contesti.

Git

E' un SCM distribuito venuto alla ribalta in tempi recentissimi perché sviluppato in extremis da Linux Torvalds e altri kernel hacker per la gestione dei sorgenti del kernel, a seguito di noti problemi e polemiche relativamente al precedente sistema proprietario Bitkeeper utilizzato. Come per tutti i sistemi distribuiti, chi usa git (o un suo front-end come cogito) lavora su un proprio albero locale che è un clone del tree di qualcun altro, generalmente di quello considerato il repository centrale. Lo stile di lavoro prevede che esista tipicamente un integrator che ha il compito di effettuare il merge di alberi derivati dai singoli developer nel repository ufficiale. I singoli developer effettuano i commit direttamente in locale sulla propria macchina e una tantum producono uno snapshot dello stesso per il merge con il repo ufficiale o viceversa effettuano il merge del repo con il proprio tree. Come per Subversion, branch e tag sono semplicemente nuove directory del tree, di cui però esiste uno snapshot compatto (il git file) che può essere usato per allineare il proprio tree a quello ufficiale o a quello di chiunque altro. Git prevede anche il signing per garantire che nessuno snapshot possa essere alterato da persone non autorizzate, caratteristica importante nella gestione del kernel. Rispetto a Subversion, git è assai meno documentato, ma kernel.org ha una documentazione piuttosto completa di casi di uso e reference dei comandi. Niente a che vedere comunque con i libri disponibili per CVS o SVN. Il principale difetto di git, presente soprattutto nei primi rilasci, è la mancanza di una intefaccia uniforme e unica per tutte le operazioni. Si è criticato anche il fatto che l'informazione di stato dell'archivio non è mantenuta in forma differenziale. Su tale base è stato realizzato hg.

(da completare)

Mercurial (hg)

Altro SCM distribuito simile quindi sotto diversi aspetti a git. Se il kernel di Linux usa git, in compenso il kernel freebsd e opensolaris usano entrambi mercurial. Lo sviluppo di mercuriale è partito come fork da quello di git. Attualmente molti considerano git superiore a hg sotto alcuni punti di vista, per lo meno da quando è disponibile una interfaccia unificata a git, che in precedenza era composto da una pletora sconfinata di programmi indipendenti. Allo stato attuale la gestione dei branch e il tracking sono meno evoluti di quelli di git (vedi discussione finale in svn).

(da completare)

Arch (tla)

Altro SCM distribuito simile ai precedenti. E' probabilmente quello con il set di comandi quanto più lontano da CVS e la documentazione ed uso risultano alquanto ostici. Lo sviluppo sembra fermo, probabilmente è da considerare l'uso di Bazaar (o meglio Bazaar-ng non appena a un livello di sviluppo complessivo accettabile).

(da completare)

-- FrancescoLovergine - 07 Jul 2006
-- VittorioPalmisano - 08 Jul 2006