Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del software Strumenti di Concurrent Versioning Systems Concurrent Versioning Systems tools Anno Accademico 2015/2016 Candidato Davide Pimpinella matr. N46001828
II 2
Indice Introduzione... 1 Capitolo 1 Il controllo di versione... 5 1.1 Panoramica sui CVS... 5 1.1.1 Storia del controllo di versione... 5 1.2 Glossario... 6 1.2.1 Glossario per CVS locali e centralizzati... 6 1.2.2 Glossario per CVS distribuiti... 10 Capitolo 2 Caratterizzazione dei CVS... 11 2.1 Requisiti di un CVS... 11 2.1.1 Requisiti funzionali... 11 2.1.2 Requisiti non-funzionali... 12 2.2 Architetture del repository... 13 2.2.1 Architetture locali... 13 2.2.2 Architetture centralizzate... 13 2.2.3 Architetture distribuite... 14 2.3 Modelli di concorrenza e risoluzione conflitti... 15 2.3.1 Lock / modify / unlock... 15 2.3.2 Copy / modify / merge... 16 2.3.2 a Merge before commit... 16 2.3.2 b Commit before merge... 17 2.4 Memorizzazione delle modifiche... 17 2.5 Unità delle operazioni... 18 Capitolo 3 Strumenti per il CVS... 19 3.1 Source Code Control System (SCCS)... 19 3.2 Revision Control System (RCS)... 20 3.3 Concurrent Versions System (CVS)... 21 3.4 Apache Subversion (SVN)... 23 3.5 Monotone... 24 3.6 Git... 26 3.7 Mercurial... 30 3.8 Fossil... 31 III 3
3.9 Rational Team Concert (RTC)... 32 3.10 Altri sistemi... 33 Capitolo 4 Confronto tra CVS... 34 4.1 Tabella sintetica per alcuni CVS... 34 4.2 Confronto in base alla diffusione... 35 4.3 Confronto tra architetture... 37 4.3.1 The Cathedral and the Bazaar... 37 4.3.2 Scelta dell architettura... 38 4.4 Confronto per tipologia di progetto... 39 Conclusioni... 41 Ringraziamenti... 42 Bibliografia... 43 IV 4
Introduzione Gestione della configurazione I sistemi software vengono creati per agevolare la risoluzione di problemi e quindi è necessario che il sistema creato rispetti una determinata lista di requisiti. Considerando che nel tempo può variare la natura del problema, possono variare in corrispondenza i requisiti richiesti al sistema software specifico, il quale dovrà essere adeguato alla nuova configurazione. Inoltre, possono essere scoperti errori nell implementazione del software ai quali bisogna porre rimedio, e considerare l evolversi dei sistemi hardware e software di supporto al sistema realizzato. Il software è quindi per sua natura soggetto a variazioni nel corso del suo ciclo di sviluppo e in generale nel corso del ciclo di vita. Nasce quindi l esigenza di avere una tracciabilità delle varie versioni del sistema, per poterne garantire una manutenzione ed una gestione più strutturate. Sotto il nome di Gestione della Configurazione (Configuration Management - CM) rientrano tutte le politiche, i processi e gli strumenti per la gestione delle modifiche dei sistemi software. Nelle diverse versioni si possono riscontrare richieste di cambiamenti, correzioni di errori ed adattamenti per diverse configurazioni hardware o sistemi operativi. Ci possono essere diverse versioni in sviluppo ed in utilizzo nello stesso tempo e, se non si dispone di procedure di gestione della configurazione efficaci, si può incorrere nello spreco di sforzo per modificare la versione sbagliata di un sistema, oppure nell errore di fornire la versione sbagliata di un sistema ai clienti, o dimenticare dove il codice sorgente del software per una particolare versione del sistema o del componente è stato memorizzato. Se la gestione della configurazione è dunque utile per i singoli progetti, gestiti da una singola persona, è essenziale per i progetti di squadra dove diversi sviluppatori lavorano contemporaneamente su un sistema software. A volte questi sviluppatori lavorano nello stesso luogo geografico, ma sempre più le squadre di sviluppo hanno membri distribuiti in diverse località nel mondo. L uso di un sistema di gestione della configurazione assicura 1
che le squadre abbiano accesso alle informazioni relative ad un sistema che è in fase di sviluppo e non interferiscano con il lavoro di altri. La gestione della configurazione di un prodotto di sistema software coinvolge quattro attività strettamente connesse (Fig. 1): Gestione delle modifiche In questa attività ci si occupa di raccogliere le richieste di modifiche al software da parte dei clienti e sviluppatori, solitamente pervenute tramite CFR (Change Request Form). Inoltre, elaborando i costi e l'impatto di tali modifiche, bisogna decidere se e quando le modifiche possono essere implementate. Gestione delle versioni Questa attività, che sarà oggetto della discussione del presente elaborato, consta nel tenere traccia delle molteplici versioni dei componenti del sistema e nel garantire che le modifiche apportate ai componenti da diversi sviluppatori non interferiscano tra loro. Costituzione del sistema Questo è il processo di assemblaggio di componenti, dati e librerie, e quindi la loro compilazione e il collegamento per creare un sistema eseguibile. A sostegno di questa fase esistono strumenti detti CASE (Computer-Aided Software Engineering) alcuni dei quali implementano singole attività elementari, altri invece offrono un ambiente integrato, complesso e costoso per l intera gestione delle configurazioni. Gestione delle release In questo stadio si prepara software per il rilascio del sistema e si tiene traccia delle versioni del sistema rilasciate per l'uso del cliente. Figura 1 Attività per la Gestione della Configurazione 2
La gestione delle configurazioni comporta il trattamento di un grande volume di informazioni, dunque sono stati sviluppati molti strumenti a supporto di questa attività. Il ruolo strategico della gestione della configurazione, la rende ottima candidata ad essere considerata elemento fondamentale per la generazione di software di qualità, tanto è vero che è stata standardizzata per la certificazione di qualità sia in ISO 9000 che nei CMM e CMMI. L aumentare degli strumenti a supporto della CM ed il continuo aggiornamento e rinnovamento dei cicli di vita dei sistemi software, ha portato al crescere il numero di strumenti a supporto dell attività di gestione delle versioni. La loro evoluzione nel tempo li ha portati dall essere dei semplici gestori di codice sorgente SCM (Source Code Manager) a diventare dei sistemi di gestione delle versioni VCS (Version Control Systems). Alcune delle maggiori innovazioni si sono avute nel modello di gestione della memorizzazione, nel modello architetturale e nella gestione della concorrenza. Proprio l introduzione della gestione della concorrenza ha portato ad i sistemi di controllo di versione concorrenti detti CVS (Concurrent Versioning Systems). Scopo dell elaborato Il ventaglio si strumenti di CVS è davvero molto ampio, poiché molte sono le possibili combinazioni di caratteristiche di modello ed architetturali implementate nei tools disponibili. L esistenza di una così vasta gamma di è causa di difficoltà nella scelta dell adozione di un determinato sistema CVS rispetto ad un altro per la gestione delle versioni del proprio sistema software. Lo scopo del presente elaborato è pertanto quello di analizzare le diverse caratteristiche degli strumenti CVS e valutarne l impatto che hanno sullo sviluppo di sistemi software, in differenti condizioni di sviluppo. Presentando come casi di studio alcuni dei più diffusi tools per CVS, si vuole avere una panoramica chiara dei loro pro e contro, riscontrati in un effettivo utilizzo. 3
Struttura espositiva Il lavoro di analisi di seguito presentato segue una successione espositiva che raccoglie nel primo capitolo una panoramica sui sistemi per il controllo di versione, e la presentazione della terminologia adottata per caratterizzarne i vari aspetti. Nel successivo capitolo vengono riportati i vari elementi caratterizzanti uno strumento di CVS, come i diversi modelli e le diverse architetture adottabili per far fronte ai requisiti funzionali e non-funzionali di un tool per il CVS. Nel terzo capitolo vengono presi in analisi alcuni strumenti per il CVS seguendo l ordine di ingresso nel mercato degli stessi. Nel capitolo inerente al confronto tra strumenti per il CVS vengono messi in risalto gli elementi salienti che possono portare alla scelta di un tool rispetto ad un altro, mostrando quindi anche quali degli strumenti presentati corrisponde a tali elementi. Infine il capitolo delle conclusioni è dedicato ad una sintesi nel merito dei risultai dell analisi. 4
Capitolo 1 Il controllo di versione Per poter analizzare i sistemi a supporto del controllo di versione in maniera agevole è necessario avere un idea di insieme dell argomento trattato. In questo capitolo viene quindi proposta una introduzione nel merito dei CVS, seguita dall esposizione a grandi linee dell evoluzione storica di questi sistemi, e per finire viene illustrata la terminologia ed i concetti alla base dell analisi. 1.1 Panoramica sui CVS Un sistema di controllo di versione è una porzione di software che aiuta gli sviluppatori nel lavoro di squadra ed archivia la storia completa del loro lavoro. Ci sono tre obiettivi di base di un sistema di controllo di versione: 1. Gli sviluppatori devono essere in grado di lavorare contemporaneamente. Per ottimizzare vari fattori tra i quali il tempo di sviluppo, non si vuole essere vincolati alla serialità degli interventi dei componenti del team di sviluppo, bensì bisogna massimizzare la concorrenza. 2. Lavorando nello stesso tempo, è necessario che le varie parti sviluppate non vadano in conflitto tra loro. Questi aspetti possono essere paragonati alla programmazione multithreaded, che richiede grande attenzione da parte dello sviluppatore, caratteristiche particolari come sezioni critiche, lock, e un'istruzione di test-and-set sulla CPU. Senza questo tipo di elementi, i threads potrebbero sovrascrivere i dati in maniera errata. Un CVS fornisce la gestione della concorrenza similmente alla gestione di softeare multithreaded. 3. Si vogliono memorizzare tutte le versioni mai esistite degli elementi sotto controllo di versione. Inoltre se ne vogliono tracciare gli autori, le date di modifica ed eventualmente le motivazioni delle modifiche. 1.1.1 Storia del controllo di versione La storia dei sistemi di supporto al controllo delle versioni può essere divisa in tre generazioni. 5
Più di 40 anni di storia degli strumenti di controllo versione mostrano una tendenza costante verso una maggiore concorrenza. Negli strumenti di prima generazione, lo sviluppo simultaneo è gestito esclusivamente con locks (serrature). Solo una persona per volta può lavorare su un file. Gli strumenti di seconda generazione sono più permissivi sulle modifiche simultanee, con una limitazione notevole: gli utenti devono unire le revisioni attuali nel loro lavoro prima di essere autorizzati a fonderlo con il lavoro complessivo. La terza generazione di strumenti consente il massimo grado concorrenza per gli interventi sui file degli sviluppatori. Generazione Networking Operazioni Concorrenza Esempi Prima No Singolo file Locks SCCS, RCS Seconda Centralizzato Multi-file Terza Distribuito Changesets Merge before commit Commit before merge Tabella 1.1 Generazioni di VCS CVS, SVN, SourceSafe, Team Foundation Server, Perforce, RTC Bazaar, Git, Mercurial, Monotone, SVK 1.2 Glossario Andiamo ora ad elencare ed a chiarire la terminologia usata nell ambito dei sistemi in analisi, sia per quanto riguarda i sistemi locali e centralizzati, che per i sistemi distribuiti. Questi concetti verranno poi ripresi ed approfonditi nei successivi capitoli. 1.2.1 Glossario per CVS locali e centralizzati Repository Un repository è il luogo in cui è memorizzato tutto il lavoro relativo allo sviluppo del sistema software sotto controllo di versione. Nel repository si tiene traccia dell albero dei files, quindi la disposizione delle directory in cui sono memorizzati. Questo rende dunque un repository, un filesystem di rete. Un repository, però, è molto più di questo, infatti contiene la storia del filesystem, tanto da poter essere visto come prodotto cartesiano: Repository = Filesystem x Tempo 6
Un filesystem è bidimensionale: il suo spazio è definito da directory e file. Un repository è, invece, tridimensionale: esiste un continuum definito da directory, file e tempo. Un repository di controllo della versione contiene quindi tutte le versioni del codice sorgente che sia mai esistito. R Figura 1.1 - Rappresentazione grafica di un repository Istantanea di un repository Un istantanea del repository è definita come la struttura del filesystem in un determinato istante di tempo. In figura è proposta una istantanea del repository Macedonia, contenente i files banana, mela e ananas. Figura 1.2 Istantanea del repository Macedonia Working copy Una working copy è un'istantanea del repository utilizzata da uno sviluppatore per apportare modifiche. Il repository è condiviso da tutta la squadra, ma ogni sviluppatore non può modificarlo direttamente, pertanto le modifiche vengono implementate utilizzando copie di lavoro. Una working copy è ottenuta tramite l operazione definita check-out. La copia di lavoro fornisce uno spazio di lavoro privato (a volte indicato con il termine sandbox) dove ogni sviluppatore può operare in maniera autonoma e protetta, anche in assenza di connessione alla rete. Figura 1.3 Rappresentazione grafica di una working copy 7 C i
Commit L operazione di commit consiste nell applicare le modifiche della copia di lavoro al repository. Il commit richiede l'insieme di modifiche in corso e lo utilizza per creare una nuova versione dell'albero nel repository. Tutti i moderni strumenti di controllo versione eseguono questa operazione in modo atomico. Figura 1.4 - Commit Update L operazione di update viene eseguita quando è necessario effettuare l aggiornamento copia di lavoro per un repository esistente,. Figura 1.5 - Update Add e Delete Con questa operazione è possibile aggiungere (o rimuovere) un nuovo file alla working copy. Questa modifica si renderà effettiva nel repository solo una volta effettuato un commit. Rename Similmente a quanto detto per l operazione di add, è possibile rinominare files o directory in prima istanza in una working copy, per poi trasferire gli effetti nel repository. Si noti che questa operazione non è supportata da tutti i VCS. Move L operazione di move permette di spostare files o directory all interno dell albero del filesystem. Alcuni sistemi implementano questa operazione attraverso un uso implicito dell operazione di rename. 8
Status Con questa operazione è possibile prendere visione delle modifiche apportate ad una working copy, che si andrebbero a trasferire al repository attraverso il prossimo commit. Differencies (Diff) Status fornisce un elenco delle modifiche, ma nessun dettaglio su di esse. Per vedere esattamente quali modifiche sono state fatte, è necessario utilizzare l'operazione diff. I vari VCS implementano diff in modi diversi. Per un'applicazione a riga di comando avverrà una semplice stampa su consolle delle differenze tra il file e la sua versione modificata. Altri VCS lanciano un'applicazione diff con interfaccia grafica più elaborata. Reverte Annulla modifiche che sono state apportate alla copia di lavoro. Log Mostra la cronologia delle modifiche apportate al repository. Abbiamo visto che il repository tiene traccia di tutte le versioni. Si visualizzano tutti i set di cambiamenti (changeset) eseguiti nelle varie versioni, insieme ai dati aggiuntivi quali l autore delle modifiche, l istante temporale. Tag Questa operazione permette di associare un nome significativo ad una versione specifica versione del repository. Questo è utile per distinguere tra loro le release di un software. Branch Con l operazione di branch è possibile creare un'altra linea di sviluppo. Si usa quando si desidera che il processo di sviluppo proceda in due direzioni diverse. Ad esempio, quando si rilascia la versione 3.0, si potrebbe desiderare di creare un ramo 4.0 in modo che lo sviluppo delle sue caratteristiche rimanga separato dal ramo 3.0.x bug-fix. MAIN 3.0 4.0 BUG FIX 3.0.1 Figura 1.6 Esempio generazione di un branch 9
Merge Il merge applica le modifiche di un ramo ad un altro. In genere quando si è utilizzato ramo per consentire uno sviluppo parallelo, successivamente si desidera far convergere, almeno in parte, i due rami. In linea con l esempio precedente, se è stato creato un ramo 3.0.x di bug-fix, probabilmente si desidera che tali bug-fix siano annessi alla linea principale di sviluppo. Il merge rende questa operazione semplice automatizzando le cose il più possibile. Spesso questa operazione richiede l intervento umano o la definizione preventiva di regole per la risoluzione dei conflitti che potrebbero occorrere in questa operazione. 1.2.2 Glossario per CVS distribuiti Clone L operazione di clone consente di creare una copia del repository originario. Questa non è una copia parziale di una istanza, bensì eredita tutte le funzioni del repository originario. Naturalmente, avere più di una istanza del repository genera necessità di sincronizzazione, ma l obiettivo è quello di ottenere una maggiore flessibilità come vedremo nei capitoli successivi. R CLONE Ri Figura 1.7 Operazione clone Push e Pull Push e pull sono due operazioni che permettono la sincronizzazione tra i repository. Esse consentono rispettivamente di copiare i changeset di una istanza di repository locale in uno remoto, e viceversa, come illustrato in figura. RL PUSH RR RL PULL RR a) b) Figura 1.8 a) Push; b) Pull 10
Capitolo 2 Caratterizzazione dei CVS Per continuare l analisi dei sistemi per il controllo di versione, nel seguente capitolo si evidenziano dapprima le necessità dell utente, per poi illustrare le soluzioni implementative proposte dai vari CVS. 2.1 Requisiti di un CVS Andiamo ora ad analizzare il componente di gestione delle versioni in base ad i requisiti che deve soddisfare. Si vedano a riguardo le definizioni di requisito funzionale e nonfunzionale proposte dal testo di Sommerville [1]. Requisito funzionale: Requisiti funzionali sono dichiarazioni di servizi che il sistema dovrebbe fornire, come il sistema deve reagire a particolari fattori, e come il sistema deve comportarsi in situazioni particolari. In alcuni casi, i requisiti funzionali possono anche rendere manifesto ciò che il sistema non dovrebbe fare. Requisito non-funzionale: Requisiti non-funzionali sono vincoli sui servizi o sulle funzioni offerte dal sistema. Essi comprendono vincoli temporali, vincoli sul processo di sviluppo, e vincoli imposti dalle norme. Requisiti non-funzionali spesso si applicano al sistema nel suo complesso, piuttosto che su servizi o funzioni individuali del sistema [ ]. Possiamo quindi dividere i requisiti richiesti ad un CVS come segue 1. 2.1.1 Requisiti funzionali di un CVS Identificazione delle versioni e delle release Alle versioni vengono assegnati identificatori quando sono inserite nel sistema. Questi identificatori sono generalmente basati sul nome dell'elemento sotto controllo di versione seguito da una sequenza di numeri (ad esempio Macedonia 1.3 ). Un sistema di identificazione coerente è importante poiché semplifica il problema della definizione delle configurazioni. Registrazione dello storico delle modifiche Tutte le modifiche apportate al codice di un sistema o componente devono essere 1 Si noti che l esposizione dei requisiti è espletata con linguaggio naturale non strutturato, poiché ai fini dell analisi non è necessaria formalità. 11
registrate ed elencate. È auspicabile che questi cambiamenti possano essere utilizzati per selezionare una particolare versione del sistema (tagging). Sviluppo indipendente Si richiede che diversi sviluppatori possano lavorare sullo stesso componente contemporaneamente. Il sistema di gestione delle versioni deve registrare i componenti che sono stati copiati per l'editing ed assicurare che i cambiamenti fatti in un componente da diversi sviluppatori non interferiscano. Operazioni elementari Il sistema deve implementare le operazioni elementari elencate nel Paragrafo 1.2, od almeno un sottoinsieme di esse che regoli il check-out ed il check-in dei file in maniera consistente. Gestione dei branch e delle versioni concorrenti Gli attuali processi di sviluppo traggono beneficio dalla possibilità di operare su rami paralleli e/o su versioni concorrenti dello stesso software. Gestione di progetti concorrenti. Un sistema di gestione della versione deve poter sostenere lo sviluppo di diversi progetti, che condividono componenti. 2.1.2 Requisiti non-funzionali di un CVS Standards. Un sistema per il controllo di versione di qualità deve rispettare standard per la certificazione di qualità, ad esempio ISO 9000, CMM, CMMI oppure IEEE 828-1998. Portabilità. Data l eterogeneità dei sistemi hardware e software diffusi tra gli utenti, è auspicabile un buon grado di portabilità. Affidabilità. La quantità ed il grado di sensibilità dei dati scambiati tra gli utenti richiede un alto indice di affidabilità. Gestione della memorizzazione. Il sistema deve gestire in maniera trasparente all utente la memorizzazione ottimizzata dei files sotto controllo di versione. 12
L implementazione dei requisiti sopra esposti è affidata a differenti soluzioni, che caratterizzano un ampia gamma di tipologie di sistemi per il controllo di versione. Di seguito andiamo ad analizzare gli aspetti maggiormente influenti su questa caratterizzazione. 2.2 Architettura del repository Il codice sorgente e la sua storia possono essere conservati in una singola macchina, o in più d una. Le regole di memorizzazione del repository nelle varie macchine formano così vari modelli architetturali, di seguito descritti. 2.2.1 Architettura locale È storicamente la prima soluzione adottata dai sistemi che ponevano come obiettivo un semplice controllo del codice sorgente in una unica macchina. In questo tipo di architettura il filesystem è affiancato da un semplice database che tiene traccia delle varie versioni. Computer locale R C i Figura 2.1 Architettura locale 2.2.2 Architettura centralizzata Successivamente è nata l esigenza di gestire la configurazione di sistemi software sviluppati da più utenti geograficamente dislocati, con sistemi eterogenei. Nascono così sistemi per il controllo di versione con architettura centralizzata (Centralized Version Control Systems - CVCS) nel quale viene implementato quindi il modello client-server. Gli utenti accedono a un repository master situato in un nodo server tramite un client. In genere, le macchine locali detengono solo una copia di lavoro di un albero del progetto. Le modifiche in una copia di lavoro devono essere integrate nel repository master prima di essere propagate agli altri utenti. Pur risolvendo il problema della collaborazione di sviluppatori su rete, l architettura 13
centralizzata non è immune a critiche. Una siffatta architettura espone il nodo server come unico punto di fallimento, ed inoltre all aumentare del numero di nodi client il traffico concentrato sul nodo server provoca rallentamenti non indifferenti. Computer client i Computer server C i Computer client j R C k C j Figura 2.2 Architettura centralizzata 2.2.3 Architettura distribuita In un architettura distribuita, i nodi degli sviluppatori hanno una copia completa del repository con cronologia delle versioni disponibili, oltre alle loro copie di lavoro. Le critiche sull unico nodo server mosse ai CVCS vengono così ovviate. Infatti anche se si dovesse perdere la copia originaria del repository, ogni utente dispone degli elementi per il suo completo recupero. Il traffico non viene concentrato nel solo nodo server, permettendo ad un numero più ampio di sviluppatori di collaborare senza perdite di efficienza. Computer i Computer originario C i R i R C k Computer j C j R j Figura 2.3 Architettura distribuita 14
2.3 Modelli di concorrenza e risoluzione conflitti Il modello di concorrenza descrive come viene garantita l assenza di codice insensato dovuto ad errata integrazione di sorgenti modificati in concorrenza tra più sviluppatori. Nel caso in cui più programmatori modificano lo stesso file in diverse righe di codice, il sistema può fondere le due versioni, sovrapponendo le modifiche. Se invece ci sono modifiche alle stesse righe di codice si verifica un conflitto. Un sistema di controllo di versione deve essere dotato di un meccanismo per prevenire o risolvere tali conflitti. Ci sono tre modi distinti per ottenere questo risultato. 2.3.1 Lock/ modify/ unlock Riprendendo il paragone precedentemente fatto, la strategia lock/modify/unlock è comparabile all uso di semafori binari per proteggere sezioni critiche di applicazioni concorrenti. Come risultato dell operazione di lock su un file da parte di un utente, il file in questione viene visto come in sola lettura dagli altri utenti, consentendo all utente bloccante di operare modifiche sul file senza pericolo di incorrere in conflitti dovuti alla concorrenza nella modifica. Quello che in pratica accade nella maggior parte dei CVS è che nel sistema tutti i file sono in sola lettura ed al momento della richiesta di lock su un file, ne viene creata una unica copia di lavoro modificabile, visibile dal solo utente bloccante. Questa tecnica garantisce l assenza di conflitti, ma è causa della serializzazione degli interventi degli utenti. t Figura 2.4 Esempio di lock / modify / unlock 15
Un problema che ne deriva è il fatto che un utente potrebbe non sbloccare mai un file, ponendo in starvation (attesa indefinita) tutti gli utenti interessati alla modifica del file. Una soluzione adottata da alcuni CVS è quella di permettere lo sblocco forzato da parte degli altri utenti dopo un determinato tempo di timeout. Nonostante questi problemi, il locking può essere necessario, ad esempio in casi di controllo di versione per file non testuali, come immagini, video o audio. Storicamente, il locking è stato il primo metodo di risoluzione dei conflitti, ed è associato alla prima generazione di CVS. 2.3.2 Copy/ modify/ merge I limiti del modello a serratura sono molteplici e di fondamentale importanza è il vincolo della serialità imposta agli interventi di modifica degli utenti. Per superare questo vincolo sono state elaborate diverse soluzioni, che prevedono la possibilità di creare più copie di lavoro modificabili contemporaneamente da vari utenti. A questa operazione deve però necessariamente seguire una operazione di integrazione (merge) delle copie create. Questa idea è stata nel tempo implementata seguendo principalmente due modalità, di seguito presentate. 2.3.2a Merge before commit In un sistema con merge-before-commit (fusione prima del commit), il sistema di controllo di versione stampa un avviso se si tenta un commit se durante l editing uno o più file interessati sono stati modificati anche da altri utenti. Con l avviso si richiede di risolvere il conflitto prima di poter completare il commit. INIZIO Modifica WC Check-in Merge Commit Check-out working copy V Conflitti? F FINE Figura 2.5 Flow chart del merge-before-commit 16
Quando occorrono conflitti in fase di merge vengono presentate all utente le linee di codice (o le parti di file) in conflitto e viene presentata la richiesta di risoluzione del conflitto, condizione necessaria per il commit. Storicamente, la tecnica merge-beforecommit è stata la seconda soluzione dei conflitti, associata a CVS centralizzati. 2.3.2b Commit before merge Una seconda soluzione di tipo copy/modify/merge propone di non bloccare mai i commit al repository. Pertanto, se il file in repository è stato modificato da un utente mentre un secondo ne stava modificando una working copy, il commit può semplicemente essere deviato su un nuovo branch. Successivamente, i rami possono rimanere separati, o qualsiasi sviluppatore può eseguire un merge, ricongiungendoli. INIZIO Modifica Check-in Commit su WC nuovo branch Merge automatico Check-out working copy F Successo merge? V FINE Figura 2.6 Flow chart del commit-before-merge Il modello di commit-before-merge porta ad uno stile di sviluppo molto fluido in cui gli sviluppatori creano e ricongiungono molti rami. Questo rende più facile le sperimentazioni. Nel caso più generale, un repository gestito con commit-before-merge può essere rappresentato con un grafo aciclico orientato (DAG). Al modello di commit-before-merge è associata la terza generazione di CVS, con architettura decentrata. 2.4 Memorizzazione delle modifiche I sistemi per la gestione di versione sono soliti fornire servizi di gestione ottimizzata della memorizzazione. In particolare esistono due modi per modellare la storia di una linea di sviluppo in base ai cambiamenti apportati ai file. Si noti che dal punto di vista dell'utente la differenza superficiale tra i due metodi è indistinguibile. Un metodo consiste nel tenere traccia di una serie di snapshot (istantanee) di un albero di file. Salvare una snapshot consiste nel fare una copia completa di tutti i file di un 17
repository in un dato istante di tempo, con opportune ottimizzazioni per ridurre la grandezza dell albero di files. L'altro metodo tiene traccia dei changeset (set di modifiche). Invece di mantenere una copia completa di ogni versione, il sistema memorizza un elenco di differenze (delta) tra una versione e un altra. Applicando il set di modifiche ad una versione sorgente (solitamente la versione più recente) può essere ri-creata una versione di destinazione. Il risultato è la creazione di un repository compatto. Revision 1.1 Revision 1.2 Revision 1.3 a) Revision 1.1 Revision 1.2 Revision 1.3 b) Revision 1.1 Delta 1.1 Delta 1.2 Figura 2.7 a)snapshot; b)changeset Come visibile in Fig. 2.7, anche se il modello differisce, questa gestione è trasparente all utente, che percepisce il medesimo risultato. Nel modello a snapshot si possono ottenere con maggior rapidità le varie versioni di un file, ma è necessario molto spazio per la loro memorizzazione. Al contrario, il modello a changeset richiede meno spazio di memoria, ma impiega più tempo per ottenere una specifica versione di un file, poiché è necessario combinare il file di origine con i delta. 2.5 Unità delle operazioni I primi sistemi per il controllo di versione, il checkin e altre operazioni hanno come unità i singoli file: ogni file ha un proprio master originario con propri commenti e la storia delle sue revisioni è separata da quella di tutti gli altri file presenti nel sistema. La tendenza dei sistemi attuali è quella di operare su set di file: un checkin può includere modifiche ai diversi file di un componente risiedente in un albero del filesystem, trattato come unità dal sistema. Ogni commento associato alla modifica non appartiene al rispettivo file, ma è relativo alla combinazione di quel set di file e la sua revisione. 18
Capitolo 3 Strumenti per il CVS L analisi si concentra in questo capitolo su sistemi per il controllo di versione presenti sul mercato. L esposizione segue l ordine cronologico dei primi rilasci da parte degli sviluppatori e pone in evidenza le caratteristiche del sistema in analisi, le sue innovazioni ed alcuni aspetti critici. 3.1 Source Code Control System (SCCS) SCCS Data prima versione 1972 Architettura repository Locale Modello per la concorrenza Lock/modify Memorizzazione Changeset Unità modifiche File Licenza Proprietaria Tabella 3.1 Caratteristiche di SCCS Come evidenziato nell introduzione, i primi strumenti a supporto della gestione delle versioni avevano un set di istruzioni limitato e operavano in locale. Il primo strumento a larga diffusione fu il Source Code Control System(SCCS) che si affacciò al mercato nel 1972. Oggi SCCS è considerato obsoleto, tuttavia il formato dei file SCCS è ancora usato internamente da alcuni sistemi di controllo versione recenti come BitKeeper. In SCCS le varie modifiche apportate ai file nei repository non generano copie ex-novo dei files, bensì la storia dei cambiamenti è affidata al salvataggio delle sole modifiche rispetto all originario, in record detti delta. Nello specifico SCCS utilizza una tecnica chiamata interleaved deltas (oppure waves) che mira a rendere simile il tempo di recupero per ogni versione del file nel repository. Un file SCCS è in formato ASCII e si compone delle seguenti parti: Checksum, ovvero la somma logica di tutti i caratteri, eccetto quelli della prima linea; Tabella Delta contenente informazioni su chi ha creato i vari delta, quando e perché. Ogni delta ha un proprio SID univoco indicante il rilascio, il livello, il ramo e la sequenza; 19
Nomi degli utenti autorizzati ad aggiungere o rimuovere delta dal file; Flags dell header che permettono di monitorare varie opzioni e di definire gli accessi; Commenti, ovvero informazioni descrittive del file in linguaggio naturale; Corpo contenente le righe di testo effettivo del file. Originariamente SCCS non aveva comandi che implementassero l operazione di diff, ma fu successivamente aggiunta, vista la sua importanza. Oltre una serie di bug fix nel 2000, non sono state apportate rilevanti modifiche al sistema originario di SCCS. 3.2 Revision Control System (RCS) 20 RCS Data prima versione 1982 Architettura repository Locale Modello per la concorrenza Copy/merge ; Lock/modify Memorizzazione Unità modifiche Licenza Changeset File GNU GPL (free) Tabella 3.2 Caratteristiche di RCS RCS è stato sviluppato all inizio degli anni 80 del secolo scorso da Walter F. Tichy, per lo sviluppo in locale. Le caratteristiche riportate in tabella sembrano non differire di molto da quelle di SCCS. In realtà RCS migliora molti aspetti del SCCS, ad esempio è stato pioniere nella tecnica di memorizzazione dei changeset. Come visto in precedenza SCCS utilizza la tecnica delle interleaved deltas che mira a rendere simile il tempo di recupero per ogni versione del file nel repository, mentre RCS usa il reverse delta nel quale la copia originaria è sempre la più aggiornata, e le versioni precedenti sono ri-creabili sottraendo i vari delta. In questo modo si rende più efficiente il recupero delle versioni più recenti del repository. Altre rilevanti novità introdotte da RCS sono state il supporto dei tag, che fungevano da nomi simbolici per alcune revisioni, e l introduzione di un comando di merge più strutturato.
RCS rende automatici la memorizzazione, il recupero, l identificazione ed il merging delle revisioni. Una interfaccia più usabile e la licenza GNU GPL hanno permesso una larga diffusione di questo sistema per il controllo di versione. 3.3 Concurrent Versions System (CVS) CVS Data prima versione 1986 (stabile 1990) Architettura repository Centralizzata Modello per la concorrenza Copy/merge Memorizzazione Changeset Unità modifiche File Licenza GNU GPL (free) Tabella 3.3 Caratteristiche di CVS CVS è considerato un sistema di alta qualità, perciò ampio è stato l uso che se ne è fatto, sia per sviluppo di software commerciale, che open source. È stato realizzato sotto licenza GNU GPL dopo che Dick Grune sviluppò una serie di shell nel 1986 per collaborare con i propri studenti. CVS è ad oggi presente per diversi sistemi operativi, e consente di gestire a linea di comando le principali operazioni previste dai modelli lock/modify/unlock e copy/modify/merge. È implementata una architettura client-server centralizzata nella quale tipicamente il lato server gestisce il repository contenente tutti i file da gestire e tutte le informazioni sulle versioni. Il lato client consente di effettuare tutte le operazioni riguardanti la copia locale del progetto. Ogni persona coinvolta nel progetto, ha infatti una copia locale dei file (sandbox) ottenuta tramite check-out dal repository. La gestione dei conflitti in modalità copy/modify/merge è affidata al modello merge-before-commit descritto nel Par. 2.3.2a. Similmente a quanto accade in RCS per ogni file di un progetto, sono memorizzati dei file con l aggiunta dell estensione.v. Questi file contengono l ultima revisione del sorgente e tutte le modifiche apportate. CVS usa quindi la compressione delta per files di testo, come i codici sorgente, mentre nel caso di files binari, ogni versione è memorizzata separatamente. L uso di file binari è importante per evitare la corruzione dei files. 21
Dopo aver visto un punto in comune tra RCS e CVS, vediamo quali sono alcuni vantaggi significativi di CVS rispetto al suo predecessore. In CVS è possibile eseguire scripts per gestire il log delle operazioni o implementare politiche specifiche del progetto. L architettura client/server centralizzata di CVS permette a sviluppatori dislocati geograficamente, o con con connettività lenta, di lavorare come un team unico. La storia delle versioni è tenuta nel server, mentre le macchine dei client hanno working copies per gli sviluppatori. La possibilità di avere checkouts non riservati, permette a più sviluppatori di lavorare allo stesso file contemporaneamente. CVS è dotato di un database che permette di associare a cartelle di un repository un nome, creando un modulo appartenente al sistema complessivo. Grazie a questo è possibile eseguire operazioni su un intero modulo con un singolo comando. Un analisi di CVS non sarebbe completa se non si menzionassero alcuni degli aspetti critici che lo contraddistinguono. Branching e tagging sono operazioni lente e dispendiose Difficoltà nel rimuovere o eliminare file e directory poichè non sono operazioni esplicitamente supportate Assenza di atomicità nell operazione di commit. Se un commit fallisce per un qualsiasi motivo, il sistema può rimanere in uno stato inconsistente Gestione dei file binary povera di opzioni CVS è stato usato largamente e per molti anni, diventando una tecnologia matura: In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive modus operandi and support for networked operation which allow dozens of geographically dispersed programmers to share their work fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source. [Collins-Sussman] [4] 22
3.4 Subversion (SVN) Data prima versione 2000 Architettura repository Modello per la concorrenza Memorizzazione Unità modifiche Licenza 23 Centralizzata Copy/merge; Lock/modify Changeset; Snapshot Albero Apache (free) Tabella 3.4 Caratteristiche di SVN Subversion è stato progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, pertanto comprende gran parte delle caratteristiche di CVS. Come CVS, Subversion (da ora SVN) è un software gratuito ed open-source, con la differenza che è distribuito sotto licenza Apache e non GNU GPL. Tra le caratteristiche che differenziano SVN da CVS, sono di rilevante importanza l introduzione di commit come vere transizioni atomiche ed il metodo di tracciamento delle modifiche. CVS è un sistema basato sui file e mantiene una storia delle versioni separata per ogni file, mentre SVN tiene traccia delle sole revisions (revisioni), proponendo un sistema di memorizzazione a snapshot, nelle quali anche i link simbolici sono sotto controllo di versione. L atomicità conferita all operazione di commit fa si che un commit interrotto non lasci il repository in uno stato di incoerenza. Queste caratteristiche rendono più semplici ed efficienti le operazioni di branching e il tagging, il che rappresenta un cambiamento significativo rispetto a CVS nel quale lo sviluppo ramificato necessita di maggiori risorse, ed era perciò sconsigliabile. Tra gli effetti positivi delle caratteristiche sopra citate, troviamo una più efficiente gestione dei file binari. Come server centralizzato si può usare il server Web Apache, tramite il protocollo WebDAV/DeltaV, oppure un server indipendente che usa un protocollo personalizzato
basato su TCP/IP. È estremamente semplificata la configurazione base di un server Apache per dotare il repository di un acceso via HTTP, permettendo la navigazione del repository da un qualsiasi browser. Dal punto di vista dell accesso degli utenti, SVN è dotato di un modello di autenticazione più sofisticato rispetto a CVS e permette un controllo più raffinato degli utenti. Tra le altre innovazioni, in SVN l output dei comandi è analizzabile da programmi esterni, e viene fornito un log opzionale in XML. Inoltre viene supportato un nuovo formato opzionale del repository, FSFS, che non fa uso di un gestore di database, ma memorizza le revisioni direttamente nel filesystem. SVN ha trovato larga diffusione di utilizzo anche grazie alla grande varietà di plug-in per ambienti di sviluppo integrati. Tra gli aspetti critici di SVN si annovera, come per tutti i sistemi centralizzati, una concentrazione di traffico nel punto più sensibile del sistema, ovvero il nodo server. Altre osservazioni da fare sul nodo contenente il repository sono la scarsa varietà di operazioni possibili, e la persistenza di problemi per la ridenominazione e lo spostamento dei file, che porta con sé la cancellazione della storia dello specifico file. 3.5 Monotone Monotone è un sistema di controllo di versione distribuito gratuitamente sotto licenza GNU GPL. È dotato di una interfaccia semplice e transazionale, ed è uno dei primi sistemi a distaccarsi dall ottica puramente client-server, per avvicinarsi, attraverso l adozione di una architettura distribuita, ad una logica peer-to-peer per la sincronizzazione dei files tra i vari utenti. In Monotone, vengono implementate funzioni per un merging ottimizzato rispetto alle informazioni ridondanti della storia dei files. Con Monotone vengono fatti buoni passi avanti rispetto alla gestione del branching, ed alla larga compatibilità con diversi sistemi, sia per quanto riguarda i sistemi operativi, che per software di testing di terze parti. L adozione di tecniche crittografiche come SHA-1 hash per il naming delle versioni è un elemento di novità rispetto ai precedenti CVS, e permette a Monotone di gestire in maniera completa gli spostamenti e le ridenominazioni dei files. 24
La volontà di ottimizzare i merging rispetto alla ridondanza della storia dei files e l automatizzazione, ha portato gli sviluppatori ad adottare come modello di concorrenza il commit-before-merge (trattato nel paragrafo 2.3.2b). Data prima versione 2003 Architettura repository Modello per la concorrenza Memorizzazione Unità modifiche Licenza Distrubuita Copy/merge Ibrido (changeset per i file e snapshot per gli alberi) Albero GNU GPL Tabella 3.5 Caratteristiche di Monotone Per quanto riguarda i protocolli per le connessioni tra i nodi della rete distrubuita, Monotone in origine ne supportava una varietà, mentre attualmente si è scelto di supportare un solo protocollo proprietario chiamato Netsync, che è robusto ed efficiente. In questo VCS l attenzione all integrità dei files e del sistema in generale sono di primaria importanza, rispetto alle performance in termini di rapidità, che spesso vengono sacrificate. Questa caratteristica del sistema può essere ravvisata immediatamente da un utente che effettua la sottoscrizione ad un repository. Per le operazioni preliminari all utilizzo, Monotone obbliga l utente a fare un clone completo del repository e di una base di dati di grandi dimensioni, seguiti da una validazione e vari test di integrazione esaustivi e spesso molto lenti. Nonostante le innovazioni architetturali e le garanzie di correttezza ed integrità, la scarsa ottimizzazione dei parametri prestazionali ha portato Monotone ad essere sempre meno utilizzato, specialmente con l arrivo sul mercato di altri prodotti open-souce maggiormente orientate alle prestazioni. 25
3.6 Git Data prima versione 2005 Architettura repository Distribuita Modello per la concorrenza Copy/merge Memorizzazione Snapshot Unità modifiche Albero Licenza GNU GPL Tabella 3.6 Caratteristiche di Git Git è un sistema software open-source CVS creato da Linus Torvalds e successivamente curato dalla community sotto la supervisione di Junio Hamano. Lo sviluppo del sistema è iniziato dopo che diversi sviluppatori del kernel di Linux sono stati costretti ad abbandonare l accesso ai sorgenti tramite il sistema proprietario BitKeeper, divenuto a pagamento. Il nome di GIT è stato dato dallo stesso Linus Torvalds, riferendosi ad un termine gergale britannico che indica una persona stupida o sgradevole; il sito ufficiale di GIT fornisce spiegazioni alternative, attribuendo il nome alla difficoltà di utilizzo delle prime versioni. La pagina man git descrive Git come the stupid content tracker e lo stesso Torvalds in una intervista ha dato una diversa interpretazione del nome: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." [Linus Torvalds] [10] Il progetto di Git è la sintesi dell'esperienza di Torvalds nel mantenere un grande progetto di sviluppo distribuito. L obbiettivo di Torvalds era creare un CVS utilizzabile similmente a BitKeepers, ma maggiormente performante, che non ricadesse negli errori riscontrati nei CVS esistenti. In particolare CVS veniva preso come esempio opposto del risultato che si 26
desiderava ottenere. Tra le caratteristiche volute ci sono il supporto ad un flusso di lavoro intuitivo, basato su architettura distribuita, che garantisse integrità e sicurezza. Fatta esclusione delle performance, per tutti gli altri criteri Monotone avrebbe quindi rappresentato una valida scelta. Git supporta branching e merging rapide e comode, e comprende strumenti specifici per visualizzare e navigare una cronologia di sviluppo non lineare. Come altri CVS distribuiti, Git dà a ogni sviluppatore una copia locale dell'intera cronologia di sviluppo. I repository possono essere pubblicati facilmente tramite HTTP, FTP, ssh, rsync, o uno speciale protocollo Git. Punto di forza di Git è la gestione efficiente di grandi progetti. Git è molto veloce e scalabile, infatti è tipicamente un ordine di grandezza più veloce degli altri sistemi di controllo della versione, e due ordini di grandezza più veloce per alcune operazioni. Allo stesso modo di Monotone, Git adotta una autenticazione crittografica della cronologia. I cambiamenti di nome di file e directory vengono gestiti in modo implicito invece che esplicito per ovviare al problema dei CVS che usano il nome del file per identificare la sua cronologia di revisioni, rendendo impossibile spostare un file o cambiargli nome senza interrompere la sua cronologia. Un altra caratteristica di Git è la sua modularità. Esso è infatti composto da un insieme di programmi di base scritti in linguaggio C, e molti script di shell che forniscono comodi incapsulamenti. Ciò che, però, realmente rende questo sistema innovativo è il modello di branching e merging utilizzato: permette agli sviluppatori di avere più rami locali che possono essere del tutto indipendenti, incentivando così un forte sviluppo non lineare del progetto. La creazione, il merging e l eliminazione di queste linee di sviluppo avvengono in pochi secondi. Il rebasing, alternativa locale al merging, ha come suo vantaggio il fatto che non c è creazione di un commit, ma può essere problematico poiché le modifiche effettuate su di esso non possono essere inviate al repository remoto. 27
L operazione di rebase, visibile in Fig. 3.1, infatti riscrive la storia del repository, permettendone una lesstura più lineare, ma rimuovendo parte della cronologia. ESPERIMENTO a) 4 ESPERIMENTO 2 3 5 4 MAIN 2 3 MAIN b) 4 ESPERIMENTO 2 3 4 MAIN Figura 3.1 a) merge+commit; b) rebase+commit Git implementa strategie di fusione intercambiabili, infatti ha un modello ben definito di fusione incompleta, ed ha più algoritmi (resolve, recoursive, octopus, ecc...) per tentare di completarla. Se tutti gli algoritmi falliscono, tale fallimento viene comunicato all'utente e viene sollecitata una fusione manuale. Pertanto è facile sperimentare con nuovi algoritmi di fusione. Git non registra esplicitamente le relazioni di revisione di file a nessun livello all'interno dell'albero del codice sorgente. Ciò comporta conseguenze rilevanti. Si può notare infatti che è costoso esaminare la cronologia di modifiche di un singolo file rispetto a quella dell'intero progetto. Git prevede un impacchettamento esplicito periodico degli oggetti. Ogni nuovo oggetto viene immagazzinato in un file distinto e sebbene tale file sia in un formato compresso, 28
può occupare parecchio spazio ed essere inefficiente. Questo problema è risolto dall'uso di "impacchettamenti" ("packs") che immagazzinano molti oggetti in un solo file, che hanno essi stessi una compressione delta. Continuando l analisi della gestione dei dati in Git, vediamo che sono previste due strutture dati, un indice (index) modificabile che mantiene informazioni sul contenuto della prossima revisione, che costituisce di fatto lo strato intermedio tra DB e l albero di lavoro, ed un append-only object DB che contiene quattro tipologie di oggetti: Un oggetto blob è il contenuto di un file; tali oggetti non hanno nome, data, ora, né altri metadati. Il sistema memorizza ogni versione di un file come un oggetto blob distinto; Un oggetto tree è l equivalente di una directory; Un oggetto commit collega gli oggetti albero in una cronologia. Contiene il nome di un oggetto albero, data e ora, messaggio di archiviazione (log message) ed i nomi di eventuali commit genitori; Un oggetto tag è un contenitore che contiene riferimenti ad un altro oggetto e può contenere metadati aggiuntivi riferiti ad un altro oggetto. Esso è comunemente usato per memorizzare una firma digitale di un oggetto commit per il rilascio dei dati gestiti da GIT. Ogni oggetto è identificato da un codice hash del suo contenuto: esso viene inserito nel DB in una directory corrispondente alle prime due cifre del suo codice hash, le restanti cifre costituiscono il nome del file che contiene tale oggetto. All aggiunta di un nuovo oggetto, questo viene memorizzato per intero dopo averlo compresso con zlib. 29
3.7 Mercurial Data prima versione 2005 Architettura repository Distribuita Modello per la concorrenza Copy/merge Memorizzazione Changeset Unità modifiche Albero Licenza GNU GPL Tabella 3.7 Caratteristiche di Mercurial Mercurial è un sistema per controllo di versione sviluppato da Matt Mackall ed accessibile sotto licenza GNU GPL. Confermando la tendenza dei competitors, adotta un architettura distribuita. È quasi completamente scritto in Python, ma include implementazioni di alcune funzioni in C, come la diff per file binari. Il programma ha un'interfaccia a riga di comando, ma incorpora anche un'elementare interfaccia web. Fin dalla sua pubblicazione la diffusione di Mercurial è stata limitata dalla crescita esponenziale di Git, adottato dai molti sviluppatori legati al mondo Linux. Nonostante ciò, alcuni aspetti specifici di Mercurial ne hanno permesso il suo apprezzamento da parte di un numero rilevante di sviluppatori. Alcuni di questi aspetti sono la sua documentazione dettagliata, la terminologia simile a quella di sistemi come CVS e SVN e il linguaggio principale usato per la stesura del sistema, Python. Questi elementi, oltre a favorire l apprendimento del sistema per gli utenti provenienti dai sistemi sopra citati, rende agevole la sua integrazione con estensioni realizzate ad hoc da parte di sviluppatori Python. In conclusione è possibile dire che Mercurial offre prestazioni leggermente inferiori a quelle del principale concorrente, ovvero Git, ma è comunque un sistema stabile e funzionalmente completo. 30
3.8 Fossil Data prima versione 2006 Architettura repository Distribuita Modello per la concorrenza Copy/merge Memorizzazione Snapshot Unità modifiche Albero Licenza BSD (free) Tabella 3.8 Caratteristiche di Fossil Il sistema Fossil è stato rilasciato nel 2006 da D. Richard Hipp sotto licenza GNU GPL, per poi virare su un altra licenza gratuita, BSD. Pur seguendo alcune tendenze dei precedenti sistemi, in Fossil si riscontra un cambiamento di rotta sotto vari punti di vista. Questo sistema, ad esempio, non si limita al controllo di versione di un filesystem, ma prevede la gestione di tickets, pagine wiki, note tecniche, del bug tracking, e di altri servizi per la gestione globale della configurazione. Pur adottando una architettura distribuita, Fossil, al contrario di Git, Mercurial ed altri, incoraggia uno sviluppo in stile cathedral [20], per il quale non è espressamente richiesta la presenza di un server unico centrale, ma è senza dubbio la soluzione più adatta a questo stile di sviluppo. Un altro elemento caratteristico di Fossil rispetto ai precedenti sistemi è la gestione della memorizzazione dei contenuti. Mentre in sistemi come Git vengono adottate soluzioni ad hoc, in Fossil i contenuti gestiti dal sistema sono memorizzati con il supporto di una base di dati SQLite, che per sua natura rende atomiche tutte le operazioni. Un altra caratteristica di Fossil, che lo distingue dagli altri sistemi, è la notevole semplicità per le operazioni di istallazione e setting-up di server ospitanti repository. Questa caratteristica è indicativa della natura stand-alone di Fossil, che si contrappone a quella modulare di altri sistemi, per lo più composti da diversi tool elementari. 31
In Fossil la gestione dei rami prevede nomi persistenti dei branch, propagati attraverso push e pull. In tal modo tutti gli sviluppatori vedono lo stesso nome per un determinato ramo. Questo non accade ad esempio in Git, dove i rami hanno nomi locali, quindi sviluppatori che lavorano allo stesso progetto possono usare differenti nomi per lo stesso branch. Infine si noti la possibilità di tracciare tutti i repository con il comando fossil all, ed effettuare operazioni su tutti i repository tracciati, con un unico comando. 3.9 Rational Team Concert (RTC) Data prima versione 2008 Architettura repository Centralizzata Modello per la concorrenza Copy/merge; Lock/unlock Memorizzazione Changeset Unità modifiche Albero Licenza Proprietaria Tabella 3.9 Caratteristiche di RTC Rational Team Concert è un sistema per gestire la collaborazione tra più utenti per lo sviluppo di sistemi software. È sviluppato all interno del brand Rational Software acquisito da IBM e rilasciato nel 2008 sotto licenza proprietaria. Rational Team Concert (da ora RTC) è disponibile sia in versione web, che in versione eseguibile, come plug-in dell ambiente di sviluppo integrato Eclipse oppure come estensione di Microsoft Visual Studio. Similmente a Fossil, anche RTC fornisce un ambiente con più servizi che consentono di controllare in maniera più ampia la configurazione del software ed il suo processo di sviluppo, includendo la gestione di assegnazione dei lavori, build management programmazione agile, definizione del processo, bug tracking e reports. RTC è costruito sulla base di IBM Jazz Platform, una tecnologia estensibile che fornisce una piattaforma di base per la gestione del processo di sviluppo e del ciclo di vita di un 32