Confronto tra gli strumenti a supporto del Concurrent Versioning System: CVS, SVN e GIT

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Ingegneria del software Confronto tra gli strumenti a supporto del Concurrent Versioning System: CVS, SVN e GIT Anno Accademico 2011/2012 Candidato: Pantaleone Nespoli matr. N

2

3 Indice Introduzione 4 Capitolo 1. Concurrent Versioning System Lock/Modify/Unlock Copy/Modify/Merge 9 Capitolo 2. Sistemi software per il controllo di versione CVS Storia Caratteristiche Comandi principali SVN Storia Caratteristiche Comandi principali GIT Storia Caratteristiche Comandi principali Atri progetti Mercurial Monotone 25 Capitolo 3. Confronto tra i sistemi per il controllo di versione Criticità CVS SVN GIT Progetti correlati 30 Conclusioni 32 Bibliografia 34 Sitografia 35 III

4 Inserire il titolo della tesi di laurea come intestazione Introduzione La gestione della configurazione (configuration managment) consiste nello sviluppare ed utilizzare gli standard e le procedure per gestire un sistema software in evoluzione: occorre controllare tali sistemi, perché perdere traccia delle modifiche apportate in taluna versione, crea problemi che portano ad ulteriori perdite economiche, in termini di costi aggiuntivi e di forza lavoro. In tutti i modelli di processi di sviluppo, essa è uno step fondamentale per la certificazione di qualità sia in ISO 9000 che nei CMM e CMMI; un esempio è IEEE , standard per i piani della gestione della configurazione[1]. Le procedure di gestione della configurazione definiscono come registrare ed elaborare le proposte di modifica al sistema, come correlarle ai componenti, e i meccanismi utilizzati per identificare le versioni del sistema. Ci sono diverse ragioni che portano allo sviluppo di diverse configurazioni per uno stesso sistema: esse possono essere prodotte per diverse piattaforme, possono incorporare funzioni specifiche richieste da un dato cliente, o altro ancora. La gestione della configurazione si divide in quattro attività fondamentali: pianificazione della gestione, gestione delle modifiche, gestione delle versioni e delle release e costruzione del sistema stesso. 4

5 Inserire il titolo della tesi di laurea come intestazione La pianificazione descrive gli standard e le procedure che dovrebbero essere utilizzate; esso dovrebbe essere organizzato in diverse sezioni con diversi obiettivi: Definire cosa dovrebbe essere gestito (oggetti della configurazione) e lo schema che si dovrebbe utilizzare per identificare queste entità; Stabilire chi è responsabile delle procedure di gestione della configurazione; Definire politiche di gestione che tutti i membri del team devono utilizzare; Specificare gli strumenti da utilizzare ed i processi adatti per utilizzare questi strumenti; Descrivere la struttura del database di configurazione utilizzato per registrare le informazioni. La gestione delle modifiche si occupa di verificare che le modifiche siano applicate al sistema in modo controllato. Le procedure di questo passo analizzano costi e benefici delle modifiche proposte (utilizzando il modulo CFR, change request form), approvano le modifiche realmente utili e registrano quali componenti del sistema sono stati modificati. I processi coinvolti nella gestione delle versioni e delle release identificano e registrano le versioni di un sistema. Una versione è un istanza di un sistema, che differisce per funzionalità, prestazioni o correzioni da altre istanze. Le versioni devono essere identificate in modo non ambiguo, utilizzando tecniche specifiche: Numerazione delle versioni; Identificazione basata su attributi: ogni componente ha un nome ed un insieme di attributi, eventualmente ordinati, associati ad ogni versione; Identificazione orientata alle modifiche: ogni componente ha un nome come nel caso precedente, ma è anche associato a uno o più richieste di modifica. Una release è, invece, una versione distribuita ai clienti. Essa non è solo codice eseguibile, ma può includere anche file di configurazione, file di dati, programma di installazione, documentazione (in formato elettronico o cartaceo), imballaggio e 5

6 Inserire il titolo della tesi di laurea come intestazione pubblicità associate. I gestori delle release devono trovare il giusto compromesso tra costo di distribuzione delle stesse e frequenza di distribuzione, in modo da mantenere vivo il mercato e non ledere gli interessi dei clienti. Per la costruzione del sistema, il supporto degli strumenti CASE (computer-aided software engineering) è fondamentale: la combinazione di questi strumenti crea i workbench per la gestione della configurazione che ne supportano tutte le attività; riscontriamo due tipologie fondamentali: Workbench aperti: gli strumenti per ogni stadio del processo sono integrati attraverso procedure aziendali standard per il loro uso. Molti di questi strumenti sono opensource e specifici per il loro uso (bug-tracking, gestione delle versioni, strumenti per il build); Workbench integrati: forniscono funzionalità integrate per la gestione delle versioni, per costruzione del sistema e per il tracciamento delle modifiche; tuttavia gli ambienti di sviluppo presenti sul mercato sono complessi e costosi. Gestire le versioni significa elaborare grandi quantitativi di informazioni, assicurandosi che le modifiche del sistema siano registrate e controllate. Gli strumenti di gestione delle versioni controllano un repository il cui contenuto è immutabile; per lavorare su un oggetto di configurazione occorre, quindi, prima estrarlo dalla repository e inserirlo in una directory di lavoro. Successivamente al lavoro apportato, si reinserisce nella repository creando automaticamente una nuova versione. Tutti i sistemi di gestione della versioni forniscono un insieme di funzionalità simili: identificazione delle versioni, gestione della memorizzazione, registrazione dello storico delle modifiche, sviluppo indipendente (gestioni dei branch e delle versioni concorrenti) e supporto di progetto (gestioni di progetti concorrenti). Tale elaborato di tesi si occuperà di approfondire aspetti riguardanti lo sviluppo corretto di versioni concorrenti, analizzandone le problematiche e fornendo una panoramica ampia riguardo gli strumenti a supporto. 6

7 Capitolo 1 Concurrent Versioning System Il Concurrent Versioning System (CVS) è un sistema di controllo delle versioni di un progetto, legato alla produzione ed alla modifica di file. In pratica, esso permette ad un gruppo di persone di lavorare simultaneamente sullo stesso gruppo di file, generalmente sorgenti di un programma, mantenendo il controllo dell evoluzione delle modifiche che vengono apportate. Per attuare questo obiettivo, il sistema CVS mantiene un deposito centrale (repository) dal quale i collaboratori di un progetto possono ottenere una copia del lavoro. I collaboratori modificano il file della propria copia di lavoro e sottopongono le loro modifiche al sistema CVS che le integra nel deposito. Il compito di un sistema CVS non si limita a questo: è possibile, nella fattispecie, ricostruire la storia delle modifiche apportate ad un gruppo di file, oltre ad essere anche possibile ottenere una copia che faccia riferimento ad una versione precedente di quel lavoro. I sistemi di controllo di versione devono risolvere lo stesso problema fondamentale: riuscire a far interagire gli utenti evitando che essi possano interferire accidentalmente. Consideriamo lo scenario illustrato in figura 1.1. Supponiamo di avere due collaboratori, che chiameremo Harry e Sally, che decidono di modificare lo stesso file del repository nello stesso momento. Se Harry salva le sue modifiche nel repository per primo, è molto probabile che Sally possa accidentalmente sovrascriverle con la propria versione aggiornata del file. Mentre la versione di Harry del file non verrà persa per sempre (il sistema tiene memoria di ogni cambiamento), qualsiasi modifica apportata da Harry non sarà presente nella nuova versione del 7

8 file di Sally, perché lei non ha ricevuto le modifiche apportate da Harry. Ovviamente, questa è una situazione che vorremmo evitare. Le soluzione proposte agli sviluppatori sono due modelli concettualmente diversi: il modello lock/modify/unlock e il modello copy/modify/merge [2]. Fig. 1.1: esempio scrittura concorrente 1.1 Lock/Modify/Unlock In questo modello, il repository permette ad una sola persona alla volta di modificare un file. Questa politica di esclusione è gestita attraverso dei blocchi (lock). Harry deve bloccare un file prima di apportare modifiche allo stesso. Se Harry ha bloccato il file, Sally non potrà accedervi e bloccarlo a sua volta, non riuscendo ad apportare ulteriori modifiche. Tutto ciò che può fare è leggere il file ed aspettare che Harry abbia terminato il proprio lavoro e rilasci il blocco. In seguito, Sally può bloccare nuovamente il file e procedere con le proprie modifiche. Fig. 1.2 Modello Lock/Modify/Unlock Questo modello, però, risulta restrittivo, e spesso diventa un ostacolo per i collaboratori: 8

9 Il blocco potrebbe creare problemi di natura amministrativa: se Harry dimentica di sbloccare il file, Sally dovrà contattare un amministratore per far rilasciare il blocco di Harry. La situazione causa notevole spreco in termini di tempo e costi aggiuntivi; Il blocco potrebbe creare inutili serializzazioni: esso non permette ai collaboratori di lavorare in maniera simultanea sul file, anche se le modifiche apportate non si influenzano in nessun modo. Tuttavia in questa situazione, il dispendio è notevole. Il blocco potrebbe creare un falso senso di sicurezza: se Harry e Sally bloccano rispettivamente un file A ed un file B, che dipendono uno dall altro, è possibile che le modifiche apportate siano semanticamente incompatibili. La soluzione del blocco non è stata in grado di prevenire il problema: bloccando i file, i collaboratori hanno la sensazione di lavorare in modo sicuro ed isolato, e non si preoccupano di discutere eventuali cambiamenti incompatibili in anticipo. 1.2 Copy/Modify/Merge In questo modello, il client di ogni utente comunica con il repository e crea la propria copia di lavoro (working copy o sandbox), una riproduzione dei file e della directory di lavoro effettuando un operazione di check out. Gli utenti possono, poi, lavorare in modo parallelo, modificando le proprie copie private ed effettuando il commit. Altri programmatori potrebbero richiedere aggiornamenti della loro copia (update) al repository o generare delle ulteriori versioni. Infine, tali copie vengono fuse (merge) in una versione finale. Spesso il sistema per il controllo di versione assiste nella fase di integrazione, ma alla fine è un essere umano il responsabile di fare in modo che questo processo si compia correttamente. 9

10 Fig. 1.3 Modello Copy/Modify/Merge Cosa accade se le modifiche di Sally, di fatto, si sovrappongono a quelle di Harry? Questa situazione è chiamata conflitto. Quando Harry chiede al proprio client di fondere le ultime modifiche del repository nella sua copia di lavoro, la propria copia è etichettata come in uno stato di conflitto: egli sarà in grado di vedere entrambi gli insiemi di cambiamenti e scegliere manualmente tra questi. Una volta che Harry ha risolto manualmente i cambiamenti sovrapposti (possibilmente dopo una aver discusso con gli altri collaboratori), può salvare in maniera sicura il file integrato nella repository. In alternativa, è possibile scegliere di mantenere entrambe le versioni come alternative, generando un branch. Questo modello appare caotico, ma nella pratica funziona senza difficoltà. L utente può lavorare in parallelo con gli altri collaboratori, in quanto i conflitti in sistemi di grandi dimensioni sono rari. Inoltre, la quantità di tempo necessario per risolvere i conflitti è decisamente inferiore a quella persa nell uso di un sistema a blocchi. Alla fine, tutto si riconduce ad un fattore critico: la comunicazione tra gli utenti. Quando la comunicazione è scarna, i conflitti sia sintattici che semantici aumentano esponenzialmente, intaccando così la qualità del sistema. 10

11 Capitolo 2 Sistemi software per il controllo di versione Analizzeremo adesso gli strumenti software a supporto del Concurrent Versioning System, avendo cura di esaltare gli aspetti più importanti riguardanti le tematiche dell elaborato. 2.1 CVS Il Concurrent Versions System (CVS) è un software che implementa un sistema di controllo versione: mantiene al corrente di tutto il lavoro e di tutti i cambiamenti in un insieme di file, permettendo a diversi sviluppatori di collaborare. Esso consente di gestire a linea di comando le principali operazioni previste dai modelli lock/modify/unlock e copy/modify/merge Storia Cvs nasce come un mucchio di shell scripts scritti da Dick Grune, che utilizzò questo sistema per cooperare con i suoi studenti ad un progetto[3]: non riuscendo mai ad avere gli stessi orari, Grune ideò un sistema che permettesse loro di collaborare senza trovarsi fisicamente insieme. Mentre il codice attuale è totalmente differente da quello presente negli shell scripts, molti degli algoritmi di risoluzione dei conflitti sono tuttora presenti. Il codice che si è evoluto nella versione corrente del CVS è stato ideato nell aprile del 1989 da Briam Berliner, aiutato in seguito da Jeff Polk, e rilasciato a favore della comunità sotto GPL (GNU General Public License). Attualmente, un gruppo di volontari si occupa dello sviluppo del codice CVS e della correzione dei bug. 11

12 2.1.2 Caratteristiche Il CVS utilizza un architettura client-server: il lato server gestisce una repository contenente sia tutti i file da gestire, sia tutte le informazioni sulle versioni; esso memorizza tutte le versioni in un singolo file in un modo intelligente che conserva solo le differenze tra le versioni. Il client, invece, si connette al server per ottenere una propria copia del file (working copy o sandbox) nella propria directory di lavoro (working directory); al termine della modifica, lo reinserisce all interno della repository (commit). Generalmente, server e client girano su macchine diverse, ma è possibile anche trovare il server su una delle macchine client. All interno della repository sono salvati gli history files per ogni file sotto controllo di versione, etichettati con una v alla fine del nome: questi file contengono, tra le altre cose, informazioni per ricreare ogni versione del file, tutti i messaggi di commit e l username della persona che ha effettuato il commit. Il sistema CVS assegna automaticamente un numero di versione unico ad ogni file (1.1, 3.2.1), incrementando di un unità il numero più a destra ad ogni modifica (1.1, 1.2, 1.3 e così via). Nel caso la numerazione di default non sia soddisfacente, il client può rinominare a proprio piacimento il numero di versione, utilizzando il l opzione -r del commit. È possibile dare anche un nome simbolico ad alcune versioni, utilizzando il comando tag: esso permette, oltre ad annotare le versioni, di inserire informazioni aggiuntive; il tag risulta molto utile per distinguere tra loro le diverse release di un software. CVS non è limitato ad uno sviluppo lineare: esso permette di isolare i cambiamenti su una linea separata ed indipendente di sviluppo, conosciuto come ramo (branch). Ogni branch ha un proprio numero, ottenuto inserendo un numero intero al numero di versione da cui il ramo parte. Quando si modifica un file su un ramo, tali modifiche non vengono visualizzate sul tronco principale o altri rami, ma è possibile fondere i cambiamenti utilizzando il flag j branchname sul comando update. Il branch risulta molto utile per sviluppare, anche contemporaneamente, più versioni dello stesso lavoro, con scopi diversi: ad esempio, possiamo utilizzare un branch per il bug-tracking e un branch per lo sviluppo di nuove funzioni. 12

13 Riguardo alla gestione dei conflitti, CVS utilizza un modello di default chiamato unreserved checkout: in questo modello, più sviluppatori possono lavorare sulla propria sandbox simultaneamente. La prima persona che effettua il commit non ha modo di sapere se altre persone stanno lavorando sullo stesso file; le successive, invece, riceveranno un messaggio di errore quando provano ad effettuare il commit. Il sistema, in modo semiautomatico, consiglia agli sviluppatori successivi di effettuare un update/merging della versione del file nella repository; al termine, essi possiederanno una versione locale che tiene conto delle proprie modifiche e di quelle degli altri utenti. Di tale versione sarà possibile effettuare un commit, andando così a creare una versione successiva. Ad ogni modo, gli stati di un file sono visibili dagli sviluppatori con il comando status, così da poter effettuare sempre la corretta operazione senza intaccare la coerenza del sistema; da questo punto di vista, CVS cerca di facilitare la comunicazione, senza porre vincoli restrittivi come nel caso del sistema a blocchi Comandi principali La sintassi utilizzata per i comandi è: cvs [cvs_options] cvs_command [command_options] [command_args] cvs : il nome del programma; cvs_options : opzioni che influenzano i comandi; cvs_command : il comando vero e proprio; command_options : opzioni per il comando specificato; command_args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file o directory alla repository; diviene effettivo quando viene effettuato il commit. admin : interfaccia CVS per classificare strutture amministrative. annotate : specifica quale revisione modifica linee di un file. checkout : crea una working directory contenente copue dei file specificati nella richiesta. commit : inserisce i file modificati nella repository. 13

14 diff : mostra le differenze tra diverse versioni di un file. export : simile a checkout, utilizzato per esportare una copia da CVS. history : mostra gli stati dei file e degli utenti. import : importa sorgenti esterne nel CVS. init : crea una repository se non esiste. log : stampa le informazioni di log per i file. login : prompt per inserire la password dell utente. logout : rimuove la entry in.cvspass dalla repository. release : indica che il modulo non è più in uso. remove : elimina file dalla working directory, oppure intere directory. status: mostra le informazioni sui file. tag : aggiunge un tag simbolico ad una versione del file. update : sincronizza il proprio lavoro con la repository. 2.2 SVN Subversion (noto come svn, che è il nome del suo client a riga di comando) è un sistema di controllo versione libero e open-source, progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS; esso è un sistema che permette di gestire qualsiasi insieme di file, contenenti sia codice sorgente che altro[2] Storia All inizio del 2000, CollabNet Inc. iniziò a cercare sviluppatori per scrivere un software che sostituisse CVS. CollabNet offre una suite di software collaborativi chiama CollabNet Enterprise Edition (CEE); sebbene CEE usasse CVS per il controllo di versione, le limitazioni apparivano evidenti. Nel frattempo, CVS era diventato uno standard de facto nel mondo open-source, così CollabNet decise di scrivere da zero un nuovo sistema, mantenendo l idea di base di CVS, ma evitando i suoi bug e aggiungendo alcune funzionalità. Il team di sviluppo, composto da Karl Fogel, Jim Blandy, Ben Collins- Sussman, si concentrò a pieno tempo sul progetto, e il 31 Agosto 2001 Subversion divenne 14

15 self-hosting ; nel febbraio 2004 venne rilasciata al pubblico la prima versione di Subversion Caratteristiche Subversion è un sistema client/server centralizzato per la condivisione di informazioni: al centro c è la repository, che è l archivio principale di dati. Esso memorizza qualsiasi cambiamento scritto in esso nella forma di un filesystem ad albero. Come server centralizzato è possibile utilizzato un server Web Apache, tramite il protocollo WebDAV/DeltaV, oppure un server indipendente basato su TCP/IP. Fig. 2.1 Architettura SVN Ad un estremo c è il repository SVN contenente tutti i dati sotto controllo di versione; all altro estremo c è il client SVN, che controlla le copie locali. I percorsi che portano da un estremo all altro sono i metodi di accesso alla repository, che può avvenire tramite rete 15

16 o direttamente in locale, nel caso il repository sia locale appunto. A partire dalla versione 1.1, SVN gestisce due tipologie diverse di repository: la prima memorizza tutto in un database, l altra invece memorizza le informazioni direttamente nel filesystem (perciò chiamata FSFS). Vantaggi e svantaggi sono strettamente dipendenti dall uso che si intende fare, ricordando che i programmi che hanno accesso alla repository sono totalmente inconsapevoli del tipo di memorizzazione, ma che la struttura intrinseca porta differenze evidenti (dimensioni, velocità, scalabilità ). Subversion implementa un filesystem virtuale versionato che traccia i cambiamenti nel corso del tempo degli alberi delle intere directory; in questo modo, sia file che directory vengono versionate, ed è possibile effettuare su entrambe operazioni di aggiunta, cancellazione, copia e rinomina. Anche i metadati vengono posti sotto controllo di versione, come i file a cui sono associati. Per quanto concerne i numeri di versione, anche SVN utilizza un sistema di incremento numerico lineare (1.1, 1.2 ), inoltre permette di utilizzare un numero di chiavi per ricercare velocemente una particolare versione (la prima, la più recente, la precedente a), e per trovare la data in cui è stata effettuata la revisione. Un altra caratteristica senza dubbio interessante è l atomicità dei commit: un commit interrotto non lascia la repository in uno stato di incoerenza. Ciò permette agli sviluppatori di costruire ed effettuare cambiamenti come un blocco logico unico, prevenendo eventuali problemi che possono occorrere quando solo un set di modifiche vengono inviate con successo. SVN utilizza un meccanismo molto efficiente per effettuare tag e branch: l idea di base è che il costo in termini di tempo e spazio dedicato al branching e al tagging non deve essere proporzionale alla grandezza del progetto, ma alla dimensione delle modifiche. Il sistema crea branch e tag utilizzando un meccanismo simile all hard-link unix (collegamento) per copiare il progetto; in questo modo, tali operazioni utilizzano una quantità di tempo molto breve e costante. Esso è capace, inoltre, di copiare non solo singoli file, ma intere cartelle, anche se non supporta la copia tra due differenti depositi (cross-repository); ciò avviene in relazione al fatto che SVN non ha un concetto interno di branch, ma solo di copia: esso 16

17 memorizza tutta la storia riguardante quella copia, creando di fatto un ramo alternativo di progetto. In merito al modello di sviluppo, SVN utilizza copy/modify/merge per evitare i limiti che comporta il modello a blocchi; conseguentemente, ha bisogno di gestire eventuali conflitti affiorati effettuando il merging. Innanzitutto, previene l utente dall effettuare un merging erroneo tra due strutture totalmente diverse: esso infatti mostra un messaggio skipped target per indicare che altre destinazioni sono state saltate. In caso di conflitto reale, SVN assiste l utente con tre operazioni: Visualizza il file con una C per indicare il conflitto (anche durante l update); Se considera che il file possa essere fuso, inserisce dei marcatori di conflitto (conflict markers), stringhe speciali di testo che delimitano gli estremi del conflitto per rendere visibili le aree sovrapponibili; Per ogni file che ha avuto in conflitto, mette nella propria copia di lavoro tre file extra che non sono sotto controllo di versione: filename.mine (il file prima dell aggiornamento), filename.roldrev (il file nella versione BASE prima dell aggiornamento) e filename.rnewrev (il file ricevuto all aggiornamento). L utente può scegliere di compiere una delle seguenti azioni: Sistemare il conflitto a mano ; Usare uno dei file temporanei per sovrascrivere la propria copia di lavoro; Eseguire il comando svn revert per annullare le modifiche fatte in locale. Una volta risolto il conflitto, è necessario informare il sistema eseguendo il comando svn resolved: vengono così rimossi tutti i file temporanei e SVN considera il conflitto come risolto. Opzionalmente, il sistema permette anche di utilizzare il meccanismo dei blocchi per trattare file particolarmente delicati, ad esempio i file binari, dove è spesso impossibile fondere eventuali modifiche apportate da più sviluppatori Comandi principali La sintassi utilizzata per i comandi è: svn <subcommand> [options] [args] svn : il nome del programma; 17

18 subcommand : il comando vero e proprio; options : opzioni per il comando specificato; args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file, directory o link simbolici alla propria copia di lavoro. blame : mostra autore e informazioni dei revisione in-line per i file o URL specificati. cat : mostra i contenuti dei file o URL specificati. checkout : preleva dalla repository la propria copia di lavoro. cleanup : pulisce ricorsivamente la propria copia di lavoro, rimuovendo tutti i blocchi e terminando le operazioni incomplete. commit : invia le modifiche della propria copia di lavoro alla repository. copy : copia un file o una directory in una copia di lavoro o nella repository. delete : elimina un elemento da una copia di lavoro o dalla repository. diff : mostra le differenze tra due diversi path. export : esporta un albero delle directory. help : aiuto! import : importa un file o un intero albero senza controllo di versione nella repository. info : mostra informazioni su un oggetto locale o remoto. list : elenca le entry della directory specificata nella repository. lock : blocca file o URL nella repository. log : mostra i messaggi di log merge : applica le differenze tra due sorgenti. mkdir : crea una nuova directory sotto controllo di versione. move : sposta file o directory. propdel : rimuove proprietà da un oggetto. propedit : inserisce proprietà per uno o più oggetti sotto controllo di versione. propget : stampa il valore delle proprietà. 18

19 proplist : elenca tutte le proprietà. propset : setta una proprietà ad un determinato valore. resolve : rimuove lo stato conflicted dalla copie o directory di lavoro. revert : annulla tutte le modifiche locali. status : stampa lo stato delle copie o directory di lavoro. switch : aggiorna la copia di lavoro da un URL differente. unlock : blocca file o URL nella repository. update : aggiorna la copia di lavoro. 2.3 GIT Fig. 2.2 Esempio comandi SVN Git è un sistema software open-source di controllo di versione distribuito creato da Linus Torvalds. Il progetto era stato pensato inizialmente solo come motore a basso livello per poter scrivere un front-end; tuttavia in seguito si è evoluto, diventando un sistema completo di controllo versione, utilizzabile direttamente da linea di comando. Anche esso è sotto licenza GPL (GNU General Public License)[4]. 19

20 2.3.1 Storia 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. 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, diventato non più gratuito. Torvalds voleva un sistema distribuito che potesse usare come BitKeeper, ma nessuno dei sistemi disponibili soddisfaceva gratuitamente i suoi bisogni, con particolare attenzione alle prestazioni, alla salvaguardia dalla corruzione dei dati (sia intenzionale che accidentale). Lo sviluppo di GIT è cominciato nell aprile del 2005; il 16 giugno dello stesso anno è stato rilasciata la versione del kernel Linux, la prima gestita con GIT. Torvalds ha pensato deliberatamente di evitare gli approcci convenzionali, rendendo il sistema fortemente innovativo. Nel luglio del 2005 ha ceduto la manutenzione a Junio Hamano, che è il responsabile della versione 1.0 rilasciata nel dicembre 2005, ed attuale manutentore Caratteristiche La prima caratteristica di questo sistema è senz altro il server distribuito: ogni utente possiede essenzialmente un backup completo del server principale. Le modifiche sono copiate da una repository all altra, e sono importate come rami addizionali, e possono essere fusi allo stesso modo dei rami sviluppati localmente. Con questa architettura, GIT non ha un singolo point of failure, in quanto le copie possono sostituire l intero server principale in caso di incidente o corruzione dei dati; ovviamente, i workflow devono essere gestiti in maniera efficace. Inoltre, i repository possono essere facilmente pubblicati tramite i protocolli esistenti (alta compatibilità): HTTP, FTP, SSH, rsync o uno speciale protocollo GIT. GIT possiede anche un emulazione del server CVS, che consente di utilizzare gli esistenti client CVS per accedere alle repository proprie. GIT ha 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: 20

21 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. Fig. 2.3 Architettura 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. 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 21

22 creazione, il merging e l eliminazione di queste linee di sviluppo avvengono in pochi secondi, e possono essere attraversate e visualizzate senza problemi grazie all uso degli strumenti propri del sistema. Le tecniche per effettuare il merging sono intercambiabili: GIT, infatti, possiede un modello di merging incompleto, con diversi algoritmi per portarlo a termine. Nel caso in cui tutti gli algoritmi dovessero fallire, ciò viene comunicato all utente che deve effettuare un merging manuale. Inoltre, GIT offre un alternativa al merging chiamata rebasing, dal nome del comando rebase[5]; all invocazione del comando, il sistema effettua i seguenti passi: identifica ogni commit antenato del commit corrente, ma non del nuovo commit; determina cosa è cambiato per ognuno di questi commit; imposta l intestazione corrente in modo da puntare al nuovo commit; per ogni cambiamento trovato, riapplica tali cambiamenti e crea un nuovo commit. Il rebasing ha come suo vantaggio il fatto che non c è creazione di un commit, ma può essere problematico poiché l intestazione effettuata su di esso non può essere inviata alla repository remota. Fig. 2.4 Workflow GIT Come voluto dal suo creatore, GIT possiede prestazioni molto elevate: è tipicamente un ordine di grandezza più veloce degli altri sistemi di controllo di versione, addirittura due ordini per alcune operazioni. Ciò comporta una gestione efficiente dei grandi progetti, poiché esso non diminuisce le sue prestazioni all aumentare della grandezza degli stessi. Il vantaggio principale viene dall architettura stessa: comunicare localmente è molto più veloce che comunicare con un server centralizzato presente su un altra macchina. Il data model utilizzato da GIT assicura l integrità del progetto: su ogni file o commit è effettuata una checksum, e possono essere ritrovati in base a questa. Una versione dipende 22

23 dalla completa cronologia di sviluppo che ha portato a committarla; una volta che essa è stata pubblicata, non è più possibile cambiare le vecchie versioni senza che ciò venga notato. La struttura è simile ad un hash tree, ma con dati addizionali presenti sui nodi e sulle foglie Comandi principali La sintassi utilizzata per i comandi è: git <command> [options] [args] svn : il nome del programma; command : il comando vero e proprio; options : opzioni per il comando specificato; args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file dalla directory di lavoro all indice. archive : crea un file zip con il contenuto di un albero dalla propria repository. blame : mostra un file con le annotazioni su ogni riga. branch : elenca i rami esistenti. Crea un nuovo ramo se il nome specificato nella richiesta è previsto. cat-file : usato per visualizzare il tipo di un oggetto tramite il suo valore di hash. checkout : abbandona le modifiche fatte ad un file nella cartella di lavoro, sovrascrivendolo con quello presente nell ultima versione. clone : effettua una copia della repository GIT da remoto. commit : prende tutte le modifiche presenti nell indice, crea un nuovo oggetto commit che punta ad esso e setta il ramo al nuovo commit. Prevede l aggiunta obbligatoria del messaggio riferito al commit. config : setta i valori di configurazione dell utente. diff : mostra le differenze tra file nella repository, nella directory o nell indice. fetch : prende tutti gli oggetti dal repository che non sono presenti in quello locale. fsck : identifica gli oggetti corrotti tramite controllo di integrità. grep : cerca attraverso gli alberi per contenuto. 23

24 init : inizializza una repository GIT, creando una sola cartella.git nella radice. instaweb : lancia un web server con un interfaccia nella repository locale e automaticamente direziona un web browser in essa. log : mostra la lista dei commit su un ramo; esiste anche una versione grafica gitk. ls-tree : mostra un oggetto albero, inclusi il nome di ogni oggetto e il valore di hash del blob o albero che punta ad esso. merge : fonde uno o più rami nel ramo corrente e automaticamente crea un nuovo commit se non ci sono conflitti. prune : rimuove gli oggetti che non sono più puntati da alcun oggetto in un ramo. pull : prende file dalla repository remota e li fonde con i file in quella locale; equivalente ad utilizzare la sequenza fetch/merge. push : inserisce tutti gli oggetti locali modificati nel repository remoto. rebase : alternativa al merge, sposta la base di un albero innestandola altrove. reset : resetta l indice e la directory di lavoro allo stato dell ultimo commit. rm : rimuove file dall indice e dalla directory di lavoro. remote : mostra tutte le versioni remote della repository. show : mostra le informazioni di un oggetto GIT. stash : salva temporaneamente le modifiche senza committarle. status : mostra lo stato dei file nell indice. tag : etichetta un commit specifico con un semplice messaggio. 2.4 Altri progetti Per completezza della trattazione, citeremo altri sistemi di controllo di versione comunemente utilizzati, risaltandone le caratteristiche principali Mercurial Mercurial è un software multipiattaforma di controllo di versione distribuito, creato da Matt Mackall e rilasciato sotto GNU General Public License (GPL). Esso è quasi completamente scritto in Python, ma include anche un implementazione diff binaria scritta 24

25 in C; il programma ha un interfaccia da linea di comando, ma incorpora anche un elementare interfaccia web. Il sistema offre alcuni dei vantaggi tipici dei sistemi di controllo di versione distribuiti: Possibilità di lavoro degli sviluppatori anche in assenza di connessione di rete; Velocità di esecuzione dei comandi; Sicurezza del codice, poiché ogni sviluppatore possiede una copia intera della storia del progetto, che funge da backup locale per tutti gli altri utenti; Possibilità di scelta da parte del team di sviluppo di un flusso di lavoro arbitrario, non necessariamente lineare; Le funzionalità possono essere aumentate, importandole dal sito o scrivendo di proprio pugno; Facilità di utilizzo Monotone Monotone è un software open-source per il controllo di versione distribuito, scritto in C++. L idea principale al centro del progetto è di costruire un sistema che prediligesse l integrità rispetto alle prestazioni elevate peculiari ad un sistema distribuito: esso, infatti, utilizza molte primitive crittografiche per tracciare le versioni dei file (utilizzando codice hash, rendendole quindi non lineari) e per autenticare le azioni degli utenti (utilizzando la firma crittografica RSA). Monotone supporta fortemente i workflow diverge/merge, permettendo di committare il lavoro prima di effettuare il merge. Esso, però, supporta esclusivamente il protocollo netsync, ritenuto più robusto ed efficiente, e condivide alcuni concetti di base con rsync e cvsup. La facilità di utilizzo è un altra delle sue caratteristiche importanti, dovuto al set di comandi simili al più rinominato sistema CVS, di cui permette di importare interi progetti; inoltre utilizza interfacce grafiche stabili, supportate su diversi sistemi. 25

26 Capitolo 3 Confronto tra i sistemi per il controllo di versione I sistemi di controllo di versione analizzati finora sono solo una piccola parte di tutti quelli attualmente disponibili sulla rete; una domanda, a questo punto, sorge spontanea: Perché così tanti? Sono realmente necessari? Le risposte sono molteplici, e solo dopo un accurato confronto, potremo riuscire a comprenderle meglio. La differenza principale, e senza dubbio quella che prima risalta agli occhi di un osservatore, è l architettura dei sistemi appena citati: centralizzata per CVS e SVN, distribuita per GIT. Due filosofie completamente diverse nell approccio al controllo di versione, che portano con sé pregi e difetti: CVS e SVN hanno la necessità di conservare in locale solo le informazioni per raggiungere il repository remoto; tutte le modifiche vengono conservate direttamente su quello remoto, e vengono propagate tramite un commit; GIT necessita, invece, di avere una copia del repository in locale per poter condividere le proprie informazioni di versione; all atto della modifica ha bisogno prima di portarla in locale (tramite commit), e successivamente nel server remoto (tramite push). Altra differenza concettuale è il modello di dati utilizzato per gestire le modifiche ai file: CVS e SVN trattano le informazioni di versione come una catena di modifiche lineare applicate ai singoli file: in caso di commit, vengono tracciate solo le 26

27 variazioni dei file realmente modificati rispetto alla versione precedente (utilizzando la compressione delta); GIT considera i dati come una serie di snapshot (fotografie) del filesystem sotto controllo di versione: ogni volta che viene eseguito un commit, esso analizza i cambiamenti dei file sotto controllo, creando una struttura logica ad albero che mappa la struttura del filesystem stesso. La struttura dati creata sarà composta dai file modificati rispetto alla precedente versione, ed un riferimento all ultima versione modificata dei file che non sono stati oggetto di un commit: così per ogni commit, avremo uno snapshot di tutto il repository. Se da un lato è evidente la maggiore complessità di un sistema distribuito rispetto ad uno centralizzato, esso comporta vantaggi specifici: Prestazioni elevate; Maggiore flessibilità: gli sviluppatori possono lavorare anche in assenza di connessione di rete disponendo del DB in locale; Integrità dei dati, utilizzando una codifica hash; Sicurezza: disponendo di diverse copie locali dei server remoti, esistono più punti di fallimento in caso di guasti o malfunzionamenti. Inoltre, è da sottolineare come GIT rappresenti realmente un innovazione concettuale nel mondo dei sistemi di controllo di versione: con un approccio totalmente diverso, focalizzandosi su idee ben precise, è riuscito a catturare l attenzione di tantissimi utenti che lo utilizzano per lo sviluppo di software collettivo. 3.1 Criticità Andremo adesso ad analizzare le criticità dei sistemi nello specifico, elencando caso per caso i problemi più evidenti CVS Diverse caratteristiche di CVS sono state spesso soggette a critiche da parte degli sviluppatori; è da tenere, comunque, in conto che il sistema è stato progettato alla fine degli anni 80, in cui visioni di hardware e software erano molto diversi da quelle attuali. 27

28 3.1.2 SVN Le versioni create da un commit riguardano i singoli file, invece che abbracciare l intera collezione di file di un progetto o l intero repository; tale problema può essere in parte risolto con l uso dei tag. Il sistema non mette sotto controllo di versione lo spostamento o il cambiamento di nome di file o directory; ciò deriva principalmente da un problema cronologico, in quanto negli anni 80 il refactoring era molto meno comune nei processi sw. Nessun controllo di versione per i link simbolici. I commit non sono atomici. Le operazioni di branching sono dispendiose; CVS assume che la maggior parte delle operazioni avvengano sul ramo principale, con rami secondari dalla vita breve. Il sistema è ideato per trattare principalmente file di testo, e successivamente è stato modificato per supportare anche i file binari. Subversion nasce come naturale evoluzione (se vogliamo temporale) di CVS: esso, infatti, ne importa gran parte delle caratteristiche fondamentali, andando ove possibile a migliorare pecche concettuali e strutturali: Il controllo di versione è esteso anche alle intere directory, e vengono versionate anche aggiunte, copie, cancellazioni e cambiamenti di nome di file e directory; I commit effettuati sono atomici, quindi sono visti dagli sviluppatori come un blocco logico unico, e non lasciano il repository in uno stato di inconsistenza in caso di errore. Anche i metadati vengono posti sotto controllo di versione; modifica attuata in seguito alle necessità dei tempi moderni. É possibile integrare il repository con un server http Apache, rendendolo di fatto più stabile e facilitandone l interoperabilità. Le operazioni di branching e tagging sono meno dispendiose, in quanto proporzionali alla grandezza della modifica, e non a quella del progetto. 28

29 Ovviamente, anche tale sistema è affetto da problematiche: Implementa le operazioni di ridenominazione di file o directory come una copia del nuovo nome ed una cancellazione del precedente: solo il nome cambia, tutti i dati relazionati alla cronologia delle modifiche restano identici, ed il sistema utilizza ancora il vecchio nome nelle precedenti versioni dell albero. Manca delle principali feature di amministrazione e gestione del repository. Salva copie addizionali dei dati sulla macchina locale, creando problemi nel caso di progetti o file molto grandi, o nel caso di sviluppatori che lavorano su più rami contemporaneamente. Non memorizza la data delle modifiche apportate ai file, ma le date dei check-out e dei check-in GIT Abbiamo già ampiamente parlato delle innovazioni introdotte da GIT nel mondo dei sistemi di controllo versione; andiamo adesso ad analizzare le problematiche rilevate dagli utilizzatori del sistema: GIT memorizza ogni nuovo oggetto in un file distinto; ciò potrebbe causare un problema di inefficienza nonostante la compressione. Questo problema viene risolto da una sorta di impacchettamento (packs), che immagazzinano molti oggetti in un solo file, con la supposizione che file con lo stesso nome sono simili (ma funziona bene anche se la supposizione è errata). L impacchettamento deve avvenire, però, periodicamente, per mantenere alta l efficienza; Il sistema effettua istantanee degli interi alberi delle directory, rifiutando di lavorare sui singoli file come i sistemi precedenti, che applicano la compressione delta; ciò comporta ovviamente rilevanti conseguenze: diventa più costoso esaminare la cronologia delle modifiche di un singolo file rispetto a quella dell intero progetto; i cambiamenti dei nomi di file e directory vengono gestiti in modo implicito invece che esplicito: ciò può essere visto come un vantaggio rispetto ai 29

30 sistemi come CVS, ma richiede più lavoro di CPU per analizzare la cronologia. 3.2 Progetti correlati Nella trattazione dei sistemi di controllo di versione, è doveroso citare i software correlati al versioning: TortoiseCVS, un front-end client per Windows che rende l uso di CVS più facile ed intuitivo; non include un server CVS, ma supporta la creazione di repository CVS locali, fornendo supporto anche per operazioni di alto livello; TortoiseSVN, un client grafico Subversion per Windows, integrabile anche con Microsoft Visual Studio; nel 2007 ha vinto il premio di sourceforge.net come strumento più utile per gli sviluppatori votato dalla comunità; TortoiseGIT, che allo stesso modo dei precedenti è implementato come shell grafica di GIT per Windows; GIT-gui, una GUI (Graphic User Interface) per le operazioni più comuni di GIT; tale progetto è incorporato in GIT dalla versione 1.5.0, e si può lanciare tramite il comando git gui; Subclipse, progetto che integra Subversion come plug-in Eclipse. In ultima analisi, citeremo strumenti che non sono propriamente per il controllo di versione, ma aiutano gli sviluppatori di software a collaborare: sourceforge.net, una delle prime e più diffuse piattaforme web per il supporto gratuito alla realizzazione collaborativa di software; essa è nativamente integrabile con CVS; Google code, alternativa moderna a sourceforge, offre supporto allo sviluppo e all integrazione del software con tutti gli strumenti Google; offre inoltre hosting gratuito con SVN, Mercurial, Github; Dropbox, software multipiattaforma gratuito cloud based che offre un servizio di file hosting e sincronizzazione automatica di file tramite web; si basa sul protocollo 30

31 crittografico SSL e i file immagazzinati vengono cifrati tramite AES. Molto utilizzato nel web, nel 2012 ha raggiunto i 100 milioni di utenti. SkyDrive, servizio commerciale offerto da Windows Live, consente agli utenti di utilizzare un hard disk virtuale di 7 GB. 31

32 Conclusioni Le tematiche succintamente analizzate nel seguente elaborato di tesi riguardano gli aspetti più rilevanti del Concurrent Versioning System e degli strumenti correlati ad esso. Anche se agli occhi di un lettore non esperto, la trattazione di tale aspetto della vita del software potrebbe apparire superflua rispetto ad altri step più considerevoli, come la stesura del codice stesso; tuttavia questa fase assume sempre più rilievo nella progettazione. Le motivazioni vanno ricercate principalmente nei costi effettivi che questo stadio, e più generale i processi riguardanti la revisione del software, possiedono nelle moderne aziende di software design, per le quali questi processi risultano essere sempre di più un punto focale. A tale premessa, per effettuare una riflessione completa, non possiamo esimerci dal tenere in considerazione l enorme diffusione del world wide web, in quanto esso, data la facilità di accesso, è divenuto di uso estremamente comune; ciò ha generato ovviamente una serie di conseguenze sia positive che negative. Se da un lato l offerta di sistemi e strumenti collegati al controllo di versione risulta così ampia, e per lo più open source, dall altro non è così inusuale imbattersi in progetti di basso profilo, ideati e prodotti da mani non esperte e titolate. Per cui, come accade anche in tanti altri campi, sarebbe preferibile affidarsi a sistemi accreditati e referenziati da sviluppatori esperti, che fruiscono di tali strumenti già da diversi anni, piuttosto che sperimentare strumenti improvvisati e dalle prestazioni incognite. 32

33 In ultima analisi, obbiettivo di tale elaborato è fornire una risposta mirata all interrogativo posto in apertura del terzo capitolo: Perché coesistono così tanti sistemi? Sono realmente necessari? ; e soprattutto, quesito che ci poniamo adesso: qual è il migliore? La risposta più adeguata a tale domanda è un ingegneristico dipende. Le argomentazioni a supporto di tale affermazione vanno ricercate essenzialmente non tanto nelle modalità di utilizzo, rese intuitive dalle interfacce grafiche che rendono tali sistemi sempre più userfriendly, ma nei bisogni che essi soddisfano presso l utente finale: in tale scenario, la varietà di strumenti utilizzabili rappresenta senza dubbio un vantaggio, in quanto in base al progetto da sviluppare collaborativamente, è possibile scegliere quello che si adatta maggiormente alle relative esigenze. Prediligere elevate prestazioni, piuttosto che stabilità del sistema o sicurezza/integrità dei dati possono essere le chiavi d accesso per una scelta oculata da parte dei fruitori. 33

34 Bibliografia [1] Ian Sommerville, 2005, Gestione della configurazione in Ingegneria del software, Edizione 7. [2] B. Collins-Sussman, B. Fitzpatrick, C. Pilato, 2005, Controllo di versione con Subversion per Subversion 1.2. [3] Per Cederqvist, Version Managment with CVS per CVS [4] Scott Chacon, 2009, Pro Git. [5] Charles Duan, 2010, Understandeing Git conceptually. 34

35 Sitografia