Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del Software Confronto tra Concurrent Versioning Systems Anno Accademico 2014/2015 Candidato: Colella Gianni matr. N46/000465
Indice Introduzione... 4 Capitolo 1: Concurrent Versioning System... 7 1.1 Modelli... 7 1.1.1 Lock/modify/Unlock... 8 1.1.2 Copy/modify/Merge... 9 1.2 Architetture... 9 1.2.1 Sistemi di Controllo di Versione Locali... 10 1.2.2 Sistemi di Controllo di Versione Centralizzati... 10 1.2.3 Sistemi di Controllo di Versione Distribuiti... 11 Capitolo 2: Sistemi software a supporto del Concurrent Versioning System... 13 2.1 Source Code Control Sysytem... 13 2.2 Revision Control System... 14 2.3 Concurrent Versions System... 15 2.4 Subversion... 17 2.5 Bitkeeper... 19 2.6 GIT... 21 2.7 Mercurial... 24 2.8 Bazaar... 25 Capitolo 3: Confronto tra sistemi software CVS... 28 3.1 Confronto tra sistemi con architettura centralizzati... 29 3.2 Confronto tra sistemi con architettura distribuiti... 30 Conclusioni... 32 Bibliografia... 33 III
Introduzione Una delle attività più importanti del processo di sviluppo di un software è la gestione delle configurazioni: Software Configuration Management. La quale consiste nello sviluppare gli standard e le procedure per gestire un sistema software in evoluzione. A causa di continui cambiamenti dei requisiti del sistema si devono incorporare nuove versioni del sistema stesso: contemporaneamente ci possono essere diverse versioni in sviluppo e in uso, e se non si hanno a disposizione procedure efficaci di gestione della configurazione si potrebbero avere vari problemi come ad esempio la difficoltà nell individuazione del codice sorgente del software. Le procedure di gestione della configurazione definiscono come registrare ed elaborare le proposte di modifica al sistema, come correlarle ai componenti del sistema, e i metodi utilizzati per identificare le diverse versioni del sistema. La gestione delle configurazioni software è un insieme di attività ideate per gestire le modifiche di tutto il ciclo di vita di un software, la si può considerare una attività di gestione della qualità del software che è applicata in tutte le fasi del processo software. Si può schematizzare in quattro attività: pianificazione della gestione, gestione delle modifiche, gestione delle versioni e delle release e la costruzione del sistema. 4
L attività di pianificare la gestione delle configurazioni descrive gli standard e le procedure che dovrebbero essere utilizzati. E organizzato in diverse sezioni: Definire cosa deve essere gestito e lo schema da usare pe identificare queste entità. Stabilire il responsabile delle procedure di gestione della configurazione e l invio di entità controllate al team di gestione della configurazione Definire le politiche della gestione della configurazione che tutti i membri del team devono utilizzare per il controllo delle modifiche e delle versioni Specificare gli strumenti da usare per la gestione della configurazione e i processi per utilizzare questi strumenti Descrivere la struttura del Database di configurazione utilizzato per registrare le informazioni di configurazioni e quali informazioni dovrebbero essere conservate in tale database. Si possono includere anche altre informazioni nel piano di gestione della configurazione come la gestione del software ricevuto da fornitori esterni e le procedure di verifica. Le procedure di gestione delle modifiche analizzano i costi e i benefici delle modifiche proposte, approvano le modifiche utili e registrano quali componenti del sistema sono stati modificati. Il modulo di richiesta di modifica, Change Request Form - CRF, è un documento che descrive le richieste di modifica al sistema specificando costi stimati, data in cui la modifica è stata richiesta, approvata, implementata e convalidata. Una volta inviata la richiesta di modifica essa viene registrata in un database di configurazione e successivamente viene analizzata da una commissione di controllo, Change Control Board - CCB, che analizza la richiesta e decide se approvarla. I gestori delle versioni preparano procedure per assicurarsi che le versioni del sistema possano essere recuperate quando richiesto e non siano accidentalmente modificate dal team di sviluppo. Una versione di un sistema è un istanza che differisce in qualche modo da altre istanze, si possono distinguere per funzionalità, miglioramento delle prestazioni e correzione di errori software. Versioni diverse possono essere anche funzionalmente equivalenti, ma sono progettate per configurazioni hardware o software differenti. Una release del sistema è una versione che viene distribuita ai clienti. I gestori delle release 5
del sistema hanno la responsabilità di decidere quando il sistema può essere rilasciato ai clienti essa non è composta solo dal codice eseguibile ma può includere anche una documentazione, file di configurazione, programma di installazione, imballaggio e pubblicità associata. Le versioni devono essere identificate in modo non ambiguo utilizzando specifiche tecniche come la numerazione delle versioni, identificazione basata su attributi e identificazione orientata alle modifiche. La costruzione del sistema è il processo di compilazione e collegamento dei componenti software in un programma che viene eseguito su una particolare configurazione. I processi di gestione nella configurazione in genere sono standardizzati e includono l applicazione di procedure predefinite, il supporto degli strumenti C.A.S.E., Computer-aided software Engeneering, è fondamentale. Essi creano workbench per la gestione della configurazione e supportano tutte le attività; si possono riassumere in due tipologie: Workbench aperti: strumenti indipendenti che si occupano di uno degli aspetti della gestione delle versioni o delle release. Molti di questi strumenti sono open source e sono disponibili per scopi specifici, come bug tracking, gestione delle versioni o build. Workbench chiusi: Si tratta di strumenti che vanno ad integrarsi con gli ambienti di sviluppo in modo da supportare la gestione di versioni e release contestualmente allo sviluppo. Essi forniscono funzionalità integrate per la gestione delle versioni e per il tracciamento delle modifiche. I vantaggi degli ambienti di sviluppo integrati per la gestione della configurazione sono la semplificazione dello scambio dati e l inclusione nel workbench di un database integrato. Tuttavia questi ambienti di sviluppo sono complessi e costosi e quindi si preferisce utilizzare strumenti più semplici ed economici. Tale elaborato di tesi si occuperà di approfondire gli aspetti riguardanti lo sviluppo dei software a supporto del Concurrent Versioning System analizzandone i pregi e i difetti in riferimento alle diverse tipologie architetturali: Locale, Centralizzata e Distribuita. 6
Capitolo 1: Concurrent Versioning System Il Sistema di controllo delle versioni di un progetto, Concurrent Versioning System CVS, è una combinazione di tecnologie e procedure per tenere traccia e controllare i cambiamenti dei file, in particolare del codice sorgente, della documentazione e delle pagine web. In pratica si permette ad un gruppo di persone di lavorare simultaneamente sullo stesso gruppo di file mantenendo il controllo dell evoluzione delle modifiche che vengono apportate. Il controllo di versione è un aspetto fondamentale nella gestione di un progetto, in quanto ne migliora ogni componente: comunicazioni tra sviluppatori, gestione dei rilasci, gestione dei bug, stabilità del codice, tentativi di sviluppo sperimentali, e attribuzione e autorizzazione di cambiamenti da parte di alcuni sviluppatori. 1.1 Modelli Il controllo di versione mette a disposizione un deposito centrale, repository, di cui ogni sviluppatore può ottenere una copia di lavoro tramite un ckeckout; i vari sviluppatori quindi modificano i file della loro copia di lavoro e sottopongono le loro modifiche al sistema CVS che le integra nel repository. Nella maggior parte dei progetti di sviluppo software, più sviluppatori lavorano in parallelo sullo stesso software. Se due sviluppatori tentano di modificare lo stesso file contemporaneamente, in assenza di un metodo di gestione degli accessi, essi possono facilmente sovrascrivere o perdere le modifiche effettuate contestualmente. Il problema di base della condivisione di file è che le modifiche apportate da un membro del team potrebbero essere accidentalmente sovrascritti da un altro sviluppatore. 7
Figura 1.1 Esempio di overwrite In riferimento alla figura 1.1 si nota che i due tester leggono entrambi il File e tentano una modifica contemporaneamente. In assenza di CVS si produce un problema di overwrite. Per ovviare a questo problema si possono seguire due diversi approcci: 1.1.1 Lock/modify/Unlock In principio l unico modello secondo il quale i programmatori accedevano in concorrenza ai diversi file di un progetto era il modello lock/modify/unlock. Per gestire un gruppo di utenti che lavora su un progetto comune, si utilizza un server centrale con uno spazio condiviso su cui si trova il codice sorgente e avere un sistema di blocco dei file. Fig. 1.2Lock-Modify-Unlock In pratica lo sviluppatore che decide di effettuare una modifica su di un file, lo deve prima prendere in consegna in maniera esclusiva in scrittura, successivamente può modificarlo ed infine lo sblocca in modo che la nuova versione del file sia a disposizione di tutti, anche per 8
ulteriori modifiche. Da qui il nome lock-modify-unlock. 1.1.2 Copy/modify/Merge Nato negli anni '80 per sopperire ai problemi del modello precedente, questo modello introduce l'idea di permettere a più utenti di modificare lo stesso file simultaneamente e di gestire poi in maniera semiautomatica l'inclusione delle modifiche nel repository centrale. In questo modello non esistono blocchi in quanto tutti i file sono writable. Fig. 1.3 Copy-Modify-Merge Un utente copia i file del repository nella sua working copy, sandbox, apporta i cambiamenti al file della sua working folder e successivamente richiede un update della propria sandbox nel repository. I file modificati vengono uniti, merge, con quelli contenuti nel repository nella versione finale del file. L operazione di merge è tipicamente fatta in modo automatico e il risultato è tipicamente positivo anche se dopo un merge occorre verificare il corretto funzionamento dell applicazione. In alcuni casi il merge non può essere fatto automaticamente, ad esempio quando ci sono modifiche delle stesse linee di codice da parte di diversi sviluppatori, in questo caso i conflitti vengono risolti con strumenti che aiutano ad evidenziare le modifiche proprie e di altri. 1.2 Architetture I CVS possono essere realizzati secondo diverse architetture: Locale, Centralizzata e Distribuita. 9
1.2.1 Sistemi di Controllo di Versione Locali Questo approccio è molto comune in quanto semplice, ma anche incredibilmente soggetto ad errori. É facile dimenticare in quale directory ci si trova e modificare il file sbagliato o copiare dei file che non si intendeva copiare. Fig. 2.4 Sistema di Controllo di Versione Locale Per far fronte a questo problema, i programmatori svilupparono CVS locali che avevano un database semplice che manteneva tutti i cambiamenti dei file sotto controllo di revision. 1.2.2 Sistemi di Controllo di Versione Centralizzati Successivamente si dovette affrontare il problema del collaborare con altri sviluppatori su altri sistemi. Per far fronte ciò vennero sviluppati sistemi di controllo di versione centralizzati, Centralized Version Control Systems - CVCS. Fig. 1.5 Diagramma controllo di versione centralizzato 10
Questi sistemi hanno un unico server che contiene tutte le versioni dei file e un numero di utenti che scaricano i file dal server centrale. Questa impostazione offre molti vantaggi, specialmente rispetto ai CVS locali. Gli amministratori hanno un controllo preciso sui permessi concessi ai vari programmatori, quindi è molto più facile amministrare un CCVS che un database locale su ogni client. Questa configurazione ha tuttavia alcune gravi controindicazioni. La più ovvia è che il server centralizzato rappresenta il singolo punto di rottura del sistema. Se il disco rigido del database centrale si danneggia, e non ci sono i backup, il tutto viene perduto: tutta la storia del progetto ad eccezione dei singoli snapshot presenti nelle sandbox locali. 1.2.3 Sistemi di Controllo di Versione Distribuiti I Sistemi di Controllo di Versione Distribuiti, Distributed Version Control Systems DVCS, sono caratterizzati dal fatto che i client non solo controllano lo snapshot più recente dei file, ma fanno una copia completa del repository. Fig. 1.6 Diagramma del controllo di versione distribuito In questo modo se un server va in crash e i sistemi interagiscono tramite il DVCS, il repository di un qualsiasi client può essere copiato sul server per ripristinarlo. Ogni checkout è un backup completo di tutti i dati. Inoltre, molti di questi sistemi possono 11
avere più repository remoti su cui lavorare, così si può collaborare con gruppi differenti di persone in modi differenti e simultaneamente sullo stesso progetto. Questo permette di impostare diversi tipi di flussi di lavoro che non sono possibili in sistemi centralizzati, come i modelli gerarchici. Tra i modelli distribuiti andremo ad analizzare principalmente Bitkeeper, Git, Mercurial e Bazaar. 12
Capitolo 2: Sistemi software a supporto del Concurrent Versioning System Analizzo gli strumenti software a supporto del Concurrent Versioning System, esaminandone le varie caratteristiche 2.1 Source Code Control Sysytem Source Code Control Sysytem, SCCS, è uno dei primi sistemi di controllo della versione. Scritto inizialmente in SNOBOL nel 1972 da Marc Rochkind per IBM System /370, computer con sistema operativo OS/360, fu riscritto dallo stesso Rochkind in linguaggio C per i sistemi Unix. SCCS è stato il sistema di controllo versione dominante in Unix fino a quando non è stato creato RCS e poi CVS. Oggi questo sistema di controllo di versione è considerato obsoleto, tuttavia il formato dei file SCCS è ancora usato internamente da alcuni sistemi di controllo versione recenti come BitKeeper. Esso presenta un architettura locale. Un file SCCS si compone di tre parti: Tabella dei Delta,Accesso e tracciamento dei flags e corpo del testo. Invece di creare un file separato per ogni versione di un file, il file system SCCS memorizza solo le modifiche per ciascuna versione di un file. Questi cambiamenti sono indicati come delta. I cambiamenti sono monitorati dalla tabella delta in ogni file SCCS. Ogni voce nella tabella Delta contiene informazioni su chi ha creato il delta, quando hanno creato, e il motivo 13
per cui ha creato. Ogni delta ha un proprio SID univoco, SCCS Identification Number, di un massimo di quattro cifre. La prima cifra è il rilascio, la seconda cifra è il livello, la terza cifra del ramo, e la quarta cifra della sequenza. Nessuna cifra del SID può essere 0. Un esempio di un numero SID è 1.2.1.4 in cui rispettivamente 1 indica la release, 2 indica il livello, 1 il ramo 1 e 4 indica la sequenza. Per permettere il controllo e monitoraggio dei file, si utilizzano dei Flags che possono definire l'accesso e monitoraggio varie opzioni. Il corpo del file SCCS contiene il testo per tutte le diverse versioni del file. Di conseguenza, il corpo del file non sembra un file di testo standard. 2.2 Revision Control System Revision Control System (RCS) è un programma sviluppato da Walter Tichy nel 1982 con cui si fanno dei passi in avanti nella gestione di progetti software.esso mantiene, per ogni file, i dati storici ad esso relativi. Non c è la possibilità di lavorare utilizzando una rete e questo obbliga gli sviluppatori a lavorare alla stessa macchina su cui vengono salvati i dati storici del progetto oppure ad avvalersi di script che mantengano aggiornato il server RCS. In questo software manca inoltre l idea stessa di progetto, ogni file infatti viene gestito singolarmente e non ci sono relazioni tra file nemmeno se questi si trovano nella stessa directory. Il problema maggiore però deriva dallo stile di sviluppo basato sul modello lock/modify/unlock. In questo modo uno sviluppatore che desideri lavorare su un file deve prima assicurarsi dei diritti di scrittura esclusivi per quel file, tramite un lock, in modo che nessun altro possa modificarlo contemporaneamente, effettuare le modifiche e rilasciare il file con unlock. Con questo modello si rende necessaria una negoziazione tra gli sviluppatori per decidere chi possa lavorare o meno sul file in questione, con lo spiacevole imprevisto che, se un programmatore dimentica di sbloccare il file, esso non può essere modificato da altri sviluppatori. 14
2.3 Concurrent Versions System CVS, Concurrent Versions System, è un software che implementa il controllo di versione: mantiene al corrente tutto il lavoro e i cambiamenti in un insieme di file, permettendo a diversi sviluppatori di collaborare. CVS è una evoluzione del Revision Control System (RCS); fu scritto da Dick Grune negli inizi degli anni 80 per poter cooperare ad un progetto con alcuni studenti pur non riuscendo ad avere gli stessi orari. Il loro progetto funzionò dal luglio del 1984 all'agosto del 1985 permettendo di collaborare pur non stando fisicamente insieme. Nell aprile del 1989 con l intervento di Brian Berliner e Jeff Polk il codice si è evoluto nella versione corrente del CVS ed è stato rilasciato a favore della cominutà sotto GPL. Attualmente un gruppo di volontari ne gestisce il codice e la correzione dei bug. CVS utilizza un'architettura tipica di centralizzata, clientserver: un server immagazzina la versione corrente di un progetto e la sua storia, ed il client si connette al server per verificare l'ultima versione disponibile del software ed utilizzare quest'ultima. Tipicamente, client e server si connettono su una LAN o su Internet, ma il client e il server possono girare entrambe sulla stessa macchina se il CVS ha il compito di tenere traccia della storia della versione di un progetto con soltanto uno sviluppatore locale. Fig. 2.1 Copy-Modify-Merge con CVS Il software del server normalmente gira su Unix, mentre i client CVS possono girare su un 15
maggiore numero di sistemi operativi attraverso l utilizzo di front-end client come TortoiseCVS. Molti client possono simultaneamente pubblicare le copie dei progetti. Quando essi registrano poi i cambiamenti, il server tenta di fonderli. Se questo sistema fallisce, il server nega la seconda operazione di registrazione e informa il client sul conflitto, il quale sarà risolto a mano dall'utente. Se l'operazione di registrazione riesce, allora i numeri di versioni di tutti i file coinvolti si incrementano automaticamente, e il server CVS scrive una linea di descrizione fornita dall'utente, la data ed il nome dell'autore della modifica nel relativo file di log. Nel caso che la numerazione di versione nons ia soddisfacente, il client può modificare a suo piacimento il numero di versione. I client possono anche confrontare le differenti versioni dei file, richiedere una completa storia di cambiamenti, o la verifica di una fotografia storica del progetto da una certa data e da un certo numero di revisione. I client possono usare il comando per l'aggiornamento, update, al fine di uniformare le proprie copie locali con la più nuova versione presente sul server. Questo elimina l'esigenza di ripetuti download dell'intero progetto. CVS fornisce due metodi per accedere a vecchie revisioni del progetto: una si basa sull utilizzo dell inserimento della data, una seconda soluzione più efficiente invece è resa possibile grazie all utilizzo di un etichetta, tag, aggiunta a tutti i file sulla base della working copy di uno sviluppatore: CVS può anche mantenere diversi "rami", branch, di un progetto. La versione iniziale del modulo è definita head e forma il tronco dell albero; il modulo può essere spezzato in più rami, il cui sviluppo può continuare senza intaccare l head del modulo. Un modulo può avere più di un ramo che poggia sull head ed è possibile far nascere rami nuovi da quelli già esistenti. Il processo appena descritto prende il nome di Braching e consiste nel duplicare la linea di sviluppo in due rami separati. Una modifica effettuata ad un ramo non influenzerà l altro.. Il numero di progetti sviluppati utilizzando CVS è molto elevato, tra di essi, possiamo ricordare a titolo di esempio il server Web Apache. 16
2.4 Subversion Subversion, è un sistema di controllo versione per software, noto anche con il termine SVN. E stato progettato da CollabNet Inc. per essere il naturale successore di CVS considerato ormai obsoleto. Il team di sviluppo non aveva l intenzione di introdurre un nuovo approccio nella metodologia del controllo di versione, ma volevano semplicemente migliorare CVS, Decisero quindi che subversion avrebbe incluso le caratteristiche di CVS e preservato il medesimo modello di sviluppo, ma non avrebbe riproposto le ovvie debolezze; doveva essere abbastanza simile al precedente così da permettere ai clienti dell ormai diffuso CVS di poter cambiare e utilizzare Subversion con pochissima fatica. Il 31 agosto 2001, Subversion divenne self-hosting, infatti gli sviluppatori di SVN smisero di utilizzare CVS per gestire il codice di Subversion e iniziarono ad utilizzare subversion stesso; la prima versione ufficiale distribuita è datata febbraio 2004. Fig.2.2 Logo Subversion SVN è un sistema centralizzato per la condivisione delle informazioni. Difatti è presente un repository centrale per l archivio dei dati. Come server centralizzato si può utilizzare il server Web Apache, tramite il protocollo WebDAV/DeltaV, oppure un server indipendente che usa un protocollo personalizzato basato su TCP/IP. Il protocollo client/server invia solo le differenza in entrambe le direzioni, e quindi i costi di comunicazione sono proporzionali alla dimensione delle modifiche, e non alla dimensione di dati. L output dei comandi è analizzabile da un programma esterno, e viene fornito un log opzionale in XML. A partire dalle versione 1.1 sono state aggiunte notevoli cambiamenti: l innovazione principale è il supporto di un nuovo formato opzionale di repository: FSFS che non fa uso di un gestore di Database, ma memorizza le revisioni direttamente nel filesystem. Subversion implementa un filesystem "Virtuale" versionato che traccia i 17
cambiamenti nel corso del tempo degli alberi e delle intere directory: in questo modo, sia file che directory vengono versionate ed è possibile effettuare su entrambe le operazioni di rinomina, aggiunta, cancellazione e copia. L architettura Subversion : Fig. 2.3 Architettura SVN Ad un estremo c è il repository subversion che contiene tutti i dati sotto il controllo della versione, all altro estremo c è il client Subversion che gestisce le working copy. Tra questi estremi vi sono diversi percorsi tramite vari strati per l accesso al Repository. Per quanto concerne i numeri di versione, anche SVN utilizza un sistema di incremento numerico lineare permettendo di utilizzare un numero di chiavi per ricercare velocemente una particolare versione. Un altra caratteristica principale di SVN è l atomicità dei commit: quando si effettua un 18
commit, il client crea una transazione Subversion che rispecchia i cambiamenti locali e successivamente da le istruzione al repository di salvare questo albero come la istantanea successiva nella sequenza. Se il commit ha successo, la transazione è promossa in un nuovo albero di revisione e viene assegnato un nuovo numero di revisione. Se il commit fallisce per qualche ragione, la transazione viene distrutta e il client viene informato della non andata a buon fine senza lasciare 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 memorizza tutta la storia riguardante quella copia, creando di fatto un ramo alternativo di progetto. 2.5 Bitkeeper BitKeeper è un software non open-source a supporto del Concurrent Versioning System che utilizza un architettura distribuita. Il fondatore di BitKeeper, Larry McVoy, aveva lavorato ad un precedente progetto, Teamware, un prodotto da Sun per gestire lo sviluppo di Solaris, prima di creare la propria compagnia BitMover e sviluppare BitKeeper. Nel maggio 2000 è stata resa disponibile la prima release pubblica di BitKeeper L obiettivo di BitKeeper era sia per fornire un prodotto per le imprese ad un costo molto ridotto rispetto a prodotti simili, sia mettere il prodotto a disposizione del mondo open- 19
source a costo zero. BitKeeper stato usato la prima volta come una soluzione ad alcuni dei problemi causati della esponenziale crescita del kernel di Linux. Nell'aprile 2005, BitMover ha annunciato che avrebbe smesso di fornire una versione di BitKeeper gratuitamente. Oggi una licenza annuale costa a800$. Fig. 2.4Logo BitKeeper In BitKeeper, come in Teamware, gli sviluppatori "clonano" un repository esistente e lavorare all'interno di esso; l'originale è chiamato il genitore e il repository clonato è chiamato il figlio. Dal momento che il figlio è anche un repository, altri svilupatori possono clonare da esso, rendendolo sia un figlio che e un genitore. Così facendo si crea una struttura gerarchica ad albero del repository. Ci possono essere dei livelli intermedi che servono come aree di integrazione per i repository dei bambini sotto di loro. La struttura ad albero può essere riorganizzata attraverso "reparenting", Ad esempio, una possibile strategia di rilascio è clonare il repository di sviluppo, quindi Reparent il clone alla versione corrente, quindi Reparent l'albero di sviluppo per il clone. Ciò si traduce in una catena temporale ordinata di release, con ogni release del repository è figlio di una release della versione precedente del repository, e con il repository di sviluppo essendo sempre il figlio della versione più recente. Gli sviluppatori possono clonare e correggere qualsiasi rilascio del repository, e le patch possono essere propagate in avanti o indietro a tutte le versioni pertinenti, tra cui l'albero di sviluppo. Allo stesso modo, le caratteristiche sviluppate nella struttura di sviluppo possono essere propagate indietro alle versioni precedenti, se necessario. Gli sviluppatori in genere lavorano all'interno di un repository privato, di solito una delle foglie dell'albero di sviluppo. Tutti checkin sono fatti inizialmente a livello locale, e le modifiche sono private fino a 20
quando lo sviluppatore integra le modifiche con il repository genitore. Gli sviluppatori sono invitati a controllare il loro codice a livello locale di frequente, con un conseguente record storico a grana fine. Ad esempio, se un gruppo di modifiche è applicato a un repository genitore ed è risultato inaccettabile, il genitore può back-out il changeset e diventare riportato al suo stato precedente. 2.6 GIT Git è un sistema software di controllo di version creato da Linus Torvalds nel 2005. La progettazione di Git è stata ispirata a BitKeeper e da Monotone, infatti lo sviluppo di Git è iniziato dopo che BitKeeper ha ritirato la sua licenza gratuita Fig. 2.5 Logo Git Linus Torvalds voleva un sistema distribuito per gestire il kernel di Linux, ma nessuno dei sistemi disponibili gratuitamente soddisfaceva i suoi bisogni, particolarmente il suo bisogno di velocità. Lo sviluppo di Git è cominciato nell aprile 2005, nel giugno 2005 è stata pubblicata la versione 2.6.12 del kernel di Linux, la prima gestita con Git. Essendo un architettura distribuita, ogni utente possiede un backup completo del server principale; Eredita tutti i vantaggi dell architettura distribuita e infatti ogni working copy di ogni singolo sviluppatore possono sostituire l intero server in caso di guasti, è inoltre possibile integrare nella infrastruttura uno o più server GIT remoti, fondamentali per aggiungere ridondanza ai propri repository utilissimi per la condivisione dei sorgenti con altri collaboratori o colleghi. Alcuni degli obiettivi del nuovo sistema erano i seguenti: velocità, ottimo supporto allo sviluppo non lineare, capacità di gestire in modo efficiente,per velocità e dimensione dei dati, grandi progetti come il kernel Linux Fin dalla sua nascita nel 2005, Git si è evoluto ed è maturato per essere facile da usare, mantenendo tuttavia le sue qualità iniziali. A differenza della maggior parte degli altri sistemi che salvano un'informazione come una 21
lista di modifiche ai file., Git considera i propri dati più come una serie di istantanee snapshot, di un mini filesystem. Ogni volta che viene fatto un committ, o un salvataggio dello stato del progetto in Git, fondamentalmente lui fa un'immagine di tutti i file in quel momento, salvando un riferimento allo snapshot. Per essere efficiente, se alcuni file non sono cambiati, Git non li risalva, ma crea semplicemente un collegamento al file precedente già salvato. Fig. 2.6 Snaphshot in Git Questo rende Git più simile a un mini filesystem con a disposizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati e vedremo le ramificazioni (i branch) in Git nel Capitolo 3. La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali, Git non ha bisogno di connettersi al server: la legge direttamente dal tuo repository locale. Se ad esempio si vogliono visualizzare le modifiche introdotte tra la versione corrente e la versione di un mese fa di un file, Git può accedere al file com'era un mese fa e calcolare le differenze localmente, Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capitare che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene. Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di 22
una stringa di 40-caratteri, composta da caratteri esadecimali e calcolata in base al contenuto di file o della struttura della directory in Git. In Git salva tutti i committ salvati nel repository sono i riferimento ad un file non è basato sul nome del file, ma sull'hash del suo contenuto. I file in Git possono essere in tre stati: committati, modificati e n stage. Fig. 2.7 operazioni Locali Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che un file è stato contrassegnato, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. Questo ci porta alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage. La directory di Git è dove Git salva i metadati e il database degli oggetti del tuo progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer. La directory di lavoro è un checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati. L'area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. A volte viene indicato anche come 'indice', ma lo standard è definirlo come area di stage. 23
Altro aspetto innovativo in Git è il modello per realizzare branch e merge, si permette agli sviluppatori di avere più rami locali che possono essere del tutto indipendenti, così da incentivare uno sviluppo non lineare del progetto. Git possiede prestazioni molto elevate, tipicamente è un ordine di grandezza più veloce rispetto ad altri software che implementano il controllo della versione; questo aspetto comporta un vantaggio in quanto non diminuisce le sue prestazioni all aumentare della grandezza dei progetti. 2.7 Mercurial Mercurial è un software multipiattaforma di controllo di versione distribuito creato da Matt Mackall nel 2005 a causa del ritiro della versione gratuita di BitKeeper. Mackall ha deciso di scrivere un sistema di controllo di versione distribuito come un sostituto per l'uso con il kernel Linux. Questo progetto è iniziato pochi giorni dopo un altro progetto chiamato Git, iniziato da Linus Torvalds con finalità simili. Il progetto kernel di Linux ha deciso di Fig. 2.8Logo Mercurial utilizzare Git piuttosto che Mercurial, ma Mercurial è ora utilizzato da molti altri progetti E quasi completamente scritto in Python, ma include anche una implementazione diff binaria scritta in C. e disponibile sotto GNU General Public License 2.0. Il programma ha un'interfaccia a riga di comando, ma incorpora anche un'elementare interfaccia web. Inoltre può essere attivato un protocollo binario che espone molte delle funzionalità interne del programma (il cosiddetto wire protocol). Tutti i comandi di Mercurial sono invocati come opzioni del programma principale HG, un riferimento al 24
simbolo chimico dell'elemento mercurio. Sono stati realizzati da sviluppatori terzi molti client grafici dotati di GUI per renderne l'uso più agevole. Tra questi vanno menzionati almeno TortoiseHg per Windows e SmartGit/Hg (scritto in Java, perciò multipiattaforma). Se paragonato a un sistema di controllo versione centralizzato (come CVS o SVN) Mercurial offre i vantaggi seguenti (del resto comuni a tutti gli altri sistemi distribuiti): 1) Possibilità per ogni sviluppatore di lavorare anche non disponendo di una connessione di rete 2) Velocità di esecuzione dei comandi, perché ogni operazione agisce su dati residenti in locale 3) Sicurezza del codice, perché ogni sviluppatore mantiene una copia completa della storia del progetto, e quindi agisce da backup per tutti gli altri utenti 4) Libertà per il team di sviluppo di scegliere di fare uso di un flusso di lavoro arbitrario, non necessariamente legato al paradigma dell'unico repository centralizzato. 2.8 Bazaar Bazaar è un software libero, rilasciato sotto la licenza GNU GPL. E' scritto in Python e sponsorizzato da Canonical Ltd. Progettato con l obiettivo di garantire per correttezza, prestazioni, la semplicità e la familiarità per gli sviluppatori che migrano da CVS o Subversion. Dal marzo 2005 è stato auto-hosting. Fig. 2.9 Logo Di Bazaar L'obiettivo principale del team di sviluppo è quello di produrre uno strumento di controllo di revisione piacevole alla comunità del software libero. Bazaar è specificamente progettato per essere molto tollerante: ad esempio è estremamente tollerante nella rinomina di file e directory, anche quando più collaboratori differenti vogliono rinominare i file e le directory in modo diverso nei loro rami, e poi la fusione l'uno dall'altro. Se si desidera, è possibile utilizzare Launchpad come codice di hosting servizio gratuito per 25
i rami codice personale o di progetto. E 'facile da gestire il codice del progetto in Launchpad, e per tenere traccia dei contributi viene pubblicato dai membri della vostra comunità. È inoltre possibile usufruire di una facile integrazione tra il sistema di controllo di revisione e le caratteristiche di bug tracking di Launchpad. Bazaar è unico in quanto permette di impostare rami centralizzati a cui i membri del team possono continuare a impegnarsi esattamente come attualmente fanno con CVS o Subversion. In altre parole, la sua possibilità di migrare a controllo di revisione distribuito utilizzando Bazaar senza modificare radicalmente la struttura del progetto fino a quando non si è pronti ad andare completamente distribuito. Bazaar non impone restrizioni arbitrarie sul progetto. In altre parole, la comunità dovrebbe essere in grado di trattare il vostro albero come totalmente malleabile, rimodellando per migliorare la chiarezza e la struttura del codice del layout tanto quanto il contenuto dei file che compongono l'albero. Bazaar è molto flessibile, infatti può essere adattato per utilizzarlo in qualsiasi flusso di lavoro. Se si sta utilizzando un flusso di lavoro centralizzato, Bazar consente di continuare a farlo - non c'è bisogno di cambiare i processi allo stesso tempo come strumenti di cambiamento. i flussi di lavoro distribuiti possono essere introdotti gradualmente. Fig. 2.10 Flusso di Lavoro Centralizzato Altra tipologia supportata è un flusso di lavoro, deistribuito in cui con ogni sviluppatore ha il proprio ramo, o rami, più un accesso in sola lettura al ramo principale. Inoltre è presente uno sviluppatore, chiamato gatekeeper, che ha i diritti di committ per il ramo principale. Quando uno sviluppatore vuole fare un merge della sua working copy con il ramo principale, il gatekeeper fa revisione del codice e se essa soddisfa i criteri necessari, ne fa la merge. 26
Fig. 2.11Flusso di Lavoro distribuito con Getekeeper umano Gli sviluppatori di Bazaar utilizzano Un Flusso di lavoro decetrato con gatekeeper automatico. Bazaar permette di interfacciarsi con un qualsiasi bug-tracker. 27
Capitolo 3: Confronto tra sistemi software CVS Nel Capitolo 1 abbiamo fatto una prima distinzione tra le varie tipologie architetturali che si possono adottare, e abbiamo sottolineato che architetture centralizzate hanno la necessità di conservare in locale solo le informazioni per poter raggiungere il repository remoto, Come anticipato nel capitolo 1, la differenza principale, è l architettura dei sistemi appena citati: locale,per i sistemi obsoleti SCCS e RCS, centralizzata per CVS e SVN, distribuita per Bitkeeper,GIT e Mercurial. Le filosofie completamente diverse nell approccio al controllo di versione, portano con sé pregi e difetti: I sistemi con architettura locale utilizzano un modell lock-modify-unlock, e difatti sono considerati obsoleti. I sistemi con architettura centralizzata 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. I sistemi distribuiti invece necessitano 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, e successivamente nel server remoto. Se da un lato è evidente la maggiore complessità di un sistema distribuito rispetto ad uno centralizzato, esso comporta vantaggi specifici: o Prestazioni elevate 28
o maggiore flessibilità: gli sviluppatori possono lavorare anche in assenza di connessione di rete disponendo del DB in locale; o Integrità dei dati, utilizzando una codifica hash; o Sicurezza: disponendo di diverse copie locali dei server remoti, esistono più punti di fallimento in caso di guasti o malfunzionamenti. 3.1 Confronto tra sistemi con architettura centralizzati Diverse caratteristiche di CVS sono state spesso soggette a critiche da parte degli sviluppatori. 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 software. Alcuni aspetti negativi di CVS sono: - 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. In Subversion 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. 29
- É 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. Ovviamente, anche tale sistema è affetto da problematiche: mancanza delle principali feature di amministrazione e gestione del repository inoltre non c è la possibilità di salvare 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. 3.2 Confronto tra sistemi con architettura distribuiti Vi è in realtà una grande quantità di similitudini tra Git Bazaar e Mercurial. Cercherò di analizzare le aree di differenza significativa tra i sistemi. Sia Mercurial, che Bazaar che Git consentono agli utenti di estrarre selettivamente rami da altri repository. Ciò fornisce un meccanismo di anticipo per ridurre il valore della storia memorizzati localmente. In Mercurial, se un ramo è nel repository locale, allora devono essere presenti anche tutte le sue revisioni, inoltre e non c'è modo di potare i rami diversi da quelli con la creazione di un nuovo repository e selettivamente tirando rami in esso. Non è stato ancora un certo lavoro affrontare questo in Mercurial, ma nulla di ufficiale. Git supporta un numero illimitato di revisioni genitore durante un'unione. Mercurial permette solo due genitori. Per realizzare un'unione N-way in Mercurial, l'utente ne dovrà eseguire N-1 merge bidirezionali. Anche se in molti casi, questo è anche il modo migliore per unire N genitori indipendentemente DVCS, con Git l'utente può eseguire un N-senso si fondono in un unico passagg io, se lo si desidera. Mercurial è più facile da imparare rispetto a Git a causa di una serie di fattori. Git ha più comandi e opzioni, il cui volume può essere intimidatorio ai nuovi utenti. la documentazione di Mercurial tende ad essere più completo e più facile per i principianti. La terminologia e comandi di Mercurial sono anche una più vicini a Subversion e CVS, che lo rende familiare 30
a persone che migrano da questi sistemi. Git richiede una manutenzione periodica del repository, Mercurial non necessita di tale manutenzione, tuttavia Mercurial è anche molto meno sofisticato rispetto alla gestione dello spazio su disco i clienti. Abbiamo precedentemente analizzato in dettaglio le caratteristiche di Bazaar, a differenza di Git e Mercurial permette più flussi di lavoro così da facilitare il passaggio da architetture centralizzate. 31
Conclusioni Le tematiche affrontate nel seguente elaborato hanno riguardato gli aspetti più rilevanti del Concurrent Versioning System. Si è potuto constatare che negli ultimi anni l evoluzione di questi sistemi è stata sempre più grande e nella progettazione software ha assunto un ruolo considerevole. Uno degli aspetti che ha fatto si che sia sempre più necessario un controllo di versione è l abbattimento di costi in relazione a bug che possono essere tracciati risolti molto più facilmente. La scelta di un software piuttosto che un altro non è affatto semplice. Si sono visti i vantaggi di architetture distribuite, che vanno a colmare gli svantaggi delle architetture centralizzate, ma non ci sono vantaggi netti che fanno preferire sicuramente un software rispetto ad un altro: si può preferire la velocità, alla robustezza, o la scelta di un CVS privato rispetto ad uno open-source. Il tutto dipende dalle esigenze dell utente finale. Quindi a seconda della specifica si valuterà il software con le caratteristiche migliori o quello che meglio si adatta ad una determinata situazione. 32
Bibliografia [1] Ian Sommerville, 2005, ngegneria del Software [2] Bryan O'Sullivan, Mercurial: The Definitive Guide [3] Collins Sussman Fitzpatrick Pilato, Controllo di versione con subversion. [4] Vogel Blewitt, Distributed Version Control with Git [5] https://git-scm.com/book/en/v2 [6] http://wiki.bazaar.canonical.com/ [7] http://subversion.apache.org [8] http://git-scm.com [9] http://mercurial.selenic.com [10] http://tortoisesvn.net [11] http://www.nongnu.org/cvs/ [12] http://sourgeforge.net [13] http://www.bitkeeper.com/ [14] http://subversion.apache.org [15] http://oss-watch.ac.uk/resources/versioncontrol [16] http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html 33