Obiettivi

Origine dei sistemi di revisione dei cambiamenti

Le origini dei VCS/SCM (Version Control System – Software Code/Change/Configuration Manager) sono da ricercarsi agli inizi degli anni 50, quando il Dipartimento della Difesa Americano sviluppò una disciplina per la gestione dei cambiamenti a sistemi complessi detta Configuration Management.

“en.wikipedia.org > Wiki > Configuration management”:http://en.wikipedia.org/wiki/Configuration_management

1. Configuration identification
2. Configuration control
3. Configuration status accounting
4. Configuration authentication

Tali concetti sono stati adottati in diversi ambiti del management.

Evoluzione: da SCCS a RCS a CVS

• 1970: Leon Pressor pubblica una tesi riguardante il controllo delle configurazioni e i cambiamenti
• 1972: in un paper dei Bell Labs viene descritto l’algoritmo diff originale
• 1972-1975: sempre nei Bell Labs nasce il primo sistema di revisione dei cambiamenti SCCS (source code control system)
• 1980: Walter F. Tichy inizia lo sviluppo di RCS (poi diventato parte del progetto GNU)
• 1985: Larry Wall sviluppa il tool patch
• 1986: Dick Grune sviluppa CVS (sistema client-server di gestione dei cambiamenti)

Riferimenti:

• http://en.wikipedia.org/wiki/Version_control_system
• http://en.wikipedia.org/wiki/History_of_software_configuration_management
• http://en.wikipedia.org/wiki/Revision_Control_System
• http://en.wikipedia.org/wiki/Concurrent_Versions_System

Pratica: diff e patch

Su tutte le distribuzioni GNU/Linux abbiamo a disposizione i tool diff e patch che oltre a consertirci una migliore comprensione dei concetti alla base dei VCS, si possono rivelare utili in molte situazioni (anche a prescindere dalla gestione dei codici sorgente)

diff -u orig dest

patch -p0 < orig-to-dest.diff

Introduzione ai VCS (1/3)

Il controllo delle revisioni (altrimenti noto come “sistema di controllo delle versioni” (VCS) o “sistema di gestione del codice sorgente” (SCM)) permette l’organizzazioni e la gestione di differenti versioni delle stesse informazioni.

I sistemi VCS sono largamente usati nell’ingegneria e nello sviluppo software per tracciare le modifiche alle risorse utilizzate (in generale il codice sorgente, ma i VCS non si limitano a questo)

Introduzione ai VCS (2/3)

Una delle caratteristiche trasversali a tutti i VCS è la capacità di gestire le modifiche alle risorse revisionate attraverso la rete. Questi strumenti permettono dunque a più persone, non necessariamente presenti nello stesso luogo geografico di lavorare parallelamente allo stesso progetto, e di gestire in maniera più o meno complessa le modifiche a file condivisi.

In prima analisi si può quindi pensare ad un VCS come ad un file server con alcune importanti caratteristiche aggiuntive:

• accesso concorrente (simultaneo) alle risorse revisionate, sia in lettura che in scrittura
• memoria di tutte le modifiche apportate a file e directory
• possibilità di ripristinare vecchie versioni dei file
• possibilità di analizzare lo storico dei cambiamenti

Le ultime due caratteristiche inducono a guardare al VCS come a una sorta di “macchina del tempo”…

Introduzione ai VCS (3/3)

Tradizionalmente, i sistemi di controllo di versione hanno usato un modello centralizzato, in cui tutte le funzioni di controllo di versione sono eseguite da un server condiviso (repository).

In questo paradigma, il server, unico, tiene traccia delle risorse e dello storico delle revisioni, e i client (in numero indefinito) consentono di lavorare sulle risorse condivise attraverso un meccanismo di copia locale (o working-tree).

Negli ultimi anni si è imposto un modello di revisione distribuito, in cui ogni sviluppatore lavora direttamente con il suo repository locale, e le modifiche sono condivise tra i repository in un passo separato. Questa modalità di operare permette di lavorare senza una connessione di rete.

Nota: la maggior parte dei VCS usano la compressione delta, che conserva solamente le differenze fra le versioni successive dei file. Questo consente un immagazzinamento efficiente di più versioni di un file, purché, come solitamente succede, le modifiche tra una versione e la successiva riguardino solamente una piccola parte del testo.

Terminologia di base (1/2)

• Repository: Il repository è dove i file sono memorizzati, spesso su un server.

• Commit: un commit (o, più raramente, install, submit, check-in) si effettua quando si copiano le modifiche fatte su file locali nella directory revisionata (il software di controllo di versione controlla quali file sono stati modificati dall’ultima sincronizzazione).

• Modifica: una modifica (change) rappresenta uno specifico cambiamento ad un documento sottoposto al controllo di versione. La granularità delle modifiche considerate come cambiamenti varia tra i sistemi di controllo di versione.

• Change list: su molti sistemi di controllo di versione con commit di modifiche multiple atomiche, una changelist identifica un insieme di cambiamenti contenuti in un singolo commit.

• Check-out: un check-out (o checkout o co ) effettua una copia di lavoro (working tree) dal repository

• Update: un update (o sync) copia le modifiche fatte sul repository nella propria directory di lavoro (sincronizza la propria working tree con il repository)

Terminologia di base (2/2)

• Revisione: una revisione è una versione in una catena di modifiche.

• Brach: ramo di sviluppo di un repository/progetto

• Merge: un merge o integrazione unisce modifiche concorrenti in una revisione unificata.

• Import: il termine import è usato per descrivere la copiatura di un albero di directory locale sul repository.

• Export: un export è simile ad un check-out eccetto il fatto che crea un albero di directory privo dei metadati di controllo di versione (spesso è usato per la pubblicazione dei contenuti).

• Conflitto: un conflitto si presenta quando diversi soggetti fanno modifiche allo stesso documento e nello stesso punto. Non essendo il software abbastanza intelligente da decidere quale tra le modifiche è quella corretta , si richiede ad un utente di risolvere il conflitto.

• Riconciliazione: risoluzione dei conflitti, in genere effettuata manualmente col supporto di sofware e algoritmi specifici (diff, meld..)

(Wikipedia)

Limitazioni di CVS

GNU CVS è stato per moltissimo tempo il sistema di revisione dei sorgenti libero. Tuttavia con il passare del tempo le sue limitazioni (molte derivanti da precise decisioni implementative del progetto) cominciavano a farsi sentire:

• impossibilità di revisioning dei file rinominati e spostati
• impossibilità di revisioning dei link simbolici
• limitato supporto a Unicode (nei nomi e nel contenuto dei file)
• lavoro su branch limitato e inefficiente
• commit non atomici
• impossibilità di lavoro in modalità disconnessa

Fonti: http://en.wikipedia.org/wiki/Concurrent_Versions_System#Limitations

La nascita di SVN

Subversion (noto anche come svn, che è il nome del suo client a riga di comando) è un sistema di controllo di versione progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, oramai considerato superato.

Lo sviluppo di subversion inizia nel 2000, con l’intento di implementare un VCS libero che operasse come CVS, ma ne superasse le limitazioni. Dal 2001 subversion è diventato sufficientemente stabile e funzionale, da poter revisionare il suo stesso codice.

Subversion è rilasciato sotto varie licenze (librerie, client cli, tools di amministrazione del repository, etc.), tra cui Apache License, GPL v2 e una variante della Apache License.

Caratteristiche principali

La release 1.0 venne rilasciata il 23 febbraio 2004, e comprendeva le seguenti funzionalità:

• tutte le principali funzioni di CVS
• revisione di directory, metadati (proprietario, gruppo e permessi) e operazioni sui file
• commit atomici (transazioni che garantiscono la coerenza dell’operazione)
• server multiprotocollo (http, webdav, svn, sftp)
• branching e tagging veloce (non dipende dalle dimensioni dei file)
• gestione efficiente dei file binari
• compressione delta nei trasferimenti sulla rete e nella memorizzazione delle informazioni

Negli anni sono state aggiunte altre importanti caratteristiche:

• internazionalizzazione e localizzazione dei messaggi
• versioning dei link simbolici
• nuovo backend su file (utilizzabile al posto di quello originale basato su BDB)
• lock dei file inconciliabili
• versioning automatico su WebDav

Architettura di SVN

Componenti di Subversion

Subversion è costituito da una serie di componenti che consentono la gestione dei repository e del working tree:

• svn: il client a linea di comando.

• svnversion: un programma per conoscere lo stato (in termini di revisione degli elementi presenti) di una copia di lavoro.

• svnlook: un tool per ispezionare un repository Subversion.

• svnadmin: un tool per creare, operare e riparare una repository Subversion.

• svndumpfilter: un programma per filtrare i flussi di dump di una repository Subversion.

• mod_dav_svn: un modulo plug-in per il Server Apache HTTP, usato per esportare i repositories in WebDav

• svnserve: un server che è eseguito come processo demone o è invocato tramite SSH; un altro modo per rendere accessibile via rete ad altri il vostro repository.

Revisione centralizzata

Subversion è un sistema centralizzato per la condivisione delle informazioni, basato sul paradigma di interazione client/server. Al centro c’è il repository, che è l’archivio principale di dati. Il repository memorizza informazioni sotta forma di un filesystem ad albero (la tipica gerarchia di file e directory).

Quando un client legge i dati dal repository, normalmente vede solo l’ultima versione dell’albero del filesystem. Il client in realtà ha anche la possibilità di vedere uno stato precedente del filesystem. Ad esempio, un client può chiedere domande storiche come «Cosa conteneva questa directory l’ultimo Mercoledì?» oppure «Chi è stata l’ultima persona a cambiare questo file, e che modifiche ha apportato?». Queste sono le tipologie di domande che sono alla base di qualsiasi sistema di controllo di versione: sistemi che sono progettati per registrare e tenere traccia delle modifiche ai dati nel tempo.

Problemi nell’accesso concorrente

Tutti i sistemi per il controllo di versione devono risolvere lo stesso problema fondamentale: come farà il sistema a permettere agli utenti di condividere le informazioni, evitando al contempo che questi possano accidentalmente interferire fra loro?

Paradigma lock-modify-unlock (1/2)

La soluzione più semplice, implementata in molti dei primi VCS, si basa sull’utilizzo dei lock. In questo modello, il repository permette la modifica di un file solo ad un utente per volta.

Paradigma lock-modify-unlock (2/2)

L’approccio lock-modify-unlock garantisce la consistenza dedlle modifiche in ogni circostanza, ma introduce notevoli svantaggi:

• il blocco potrebbe creare problemi di natura amministrativa. A volte si può dimenticare di aver bloccato un file. Nel frattempo tutti gli altri utenti avranno le mani legate

• il lock potrebbe creare inutili serializzazioni. Cosa accade se un utente sta modificando l’inizio di un file di testo, mentre un secondo vuole semplicemente modificarne la parte finale?

• l’uso dei lock potrebbe creare un falso senso di sicurezza. Supponiamo che l’utente X blocchi e modifichi un file A, e simultaneamente l’utente Y blocchi e modifichi un file B. Ma supponiamo che A e B dipendano l’uno dall’altro, e che le modifiche apportate ad entrambi siano semanticamente incompatibili. Improvvisamente A e B non funzionano più correttamente insieme!

Modello copy-modify-merge (1/2)

Subversion utilizza il paradigma copia-modifica-fondi come alternativa al blocco. In questo modello, ciascun client crea il proprio working tree (una riproduzione locale del repository centralizzato).

Gli utenti possono così lavorare in parallelo, modificando le proprie copie private, che solo in una fase successiva verranno fuse in una nuova versione finale.

Modello copy-modify-merge (2/2)

Repository Subversion

Un tipico repository di Subversion spesso contiene i file (o codice sorgente) di diversi progetti; di solito, ogni progetto è contenuto in una sottodirectory nell’albero del filesystem del repository. Seguendo questa disposizione, la copia di lavoro di un utente corrisponderà ad uno specifico sottoalbero del repository.

Comandi di base (workflow 1/2)

Una tipica sessione di lavoro con svn si svolge grossomodo nei seguenti passi: (si suppone di aver già creato il proprio working tree da un repository remoto)

Passo 1: aggiornamento del W-T

• svn update

Passo 2: Modifica al file system

• svn add (aggiunge un file al controllo di revisione)
• svn delete (cancella un file dal repository)
• svn copy (copia un file)
• svn move (sposta/rinomina un file)
• editing (con una qualsiasi applicazione)

Comandi di base (workflow 2/2)

Passo 3: Controllo dei cambiamenti apportati al W-T

• svn status (change list)
• svn diff (differenze tra HEAD e copia locale)
• svn revert (annullamento delle modifiche su un file o su tutti i cambiamenti)

Passo 4: Controllo degli aggiornamenti sul repository

• svn update (up-to-date)

Passo 5: invio della nuova revisione

• svn commit (notare che le operazioni di update e commit sono distinte)

Nota: il passo 5 è attuabile perché si suppone che l’update al passo 4 abbia restituito un risultato “up-to-date”

Aggiornare il working tree

Segue una lista dei simboli con cui Subversion caratterizza i file in seguito ad un update:

Stato del working tree

In questa tabella sono elencati i possibili messaggi del comando svn status:

Risoluzione dei conflitti

Come abbiamo visto, si verifica un conflitto quando sussistono modifiche non integrabili automaticamente su uno stesso elemento sia sulla copia locale che sul repository centrallizzato.

Prima di effettuare un commit occorre SEMPRE fare un update per controllare che non si introducano situazioni di conflitto. Qualora il risultato di tale operazione marchi un file come conflittuale, verrano creati tre nuovi file nel proprio working tree: file.rx, file.mine e file.ry.

Per risolvere questa situazione occorre rimaneggiare tale risorsa e, una volta certi della modifica, lanciare il comando:

Solo dopo il resolved il sistema darà la possibilità di effettuare un commit

Nota: uno strumento grafico molto comodo per risolvere queste situazioni è meld

Pratica: prima interazione con svn

In questa sessione vogliamo creare una working copy da un repository già disponibile, leggerne la storia, effettuare delle modifiche ad un file e farne il commit…

# check-out di un progetto da un repository esterno
svn co file:///tmp/repo/trunk project

svn log

# modifica a file e filesystem
svn copy
editing..

svn status
svn update
svn commit
svn log

Branching, Merging e Tagging (1/2)

Branching, tagging, and merging sono concetti trasversali a tutti i sistemi di revisione.

Branching, Merging e Tagging (2/2)

Per merging si intende l’operazione di fusione tra risorse appartenenti a due branch distinti.

Il concetto di tag è strettamente correlato al ciclo di rilascio di un SW. Normalmente lo sviluppo si esegue sul trunk, prima di rilasciare una versione si crea un branch su cui eseguire test e correzioni (ad es. 1.0), e alla fine del ciclo di test si crea una copia in tags che rappresenta una release (tags/1.0.0) del progetto. La manutenzione correttiva continua sul ramo in branches, e le modifiche vengono portate in tags quando si decide di rilasciare una nuova mino release (tags/1.0.1)

Comandi per operazioni di branch, merge, e tag:

svn copy origine destinazione
svn merge -r1:2 branch_left [branch_right] [working tree]
svn copy (!)

Nota: svn merge è simile ai comandi diff e patch, ma gestisce anche le modifiche al FS

Amministrare un repository SVN

La creazione di un repository SVN è un’operazione estremamente semplice. Subversion mette a disposizione dell’utente un comodo tool di amministrazione: svnadmin

A questo punto il sistema è pronto ad accogliere risorse da revisionare. L’amministratore adesso ha facoltà di scegliere che tipo di accesso offrire all’esterno (WebDav, ssh+svnserve, svnserve). Resta comunque sempre utilizzabile l’accesso in locale, attraverso il protocollo file://

Una volta creato un repository, non resta che importarci un progetto; ciò è facilmente ottenibile con il comando:

Nota: è buona prassi creare directory di progetto con, al primo livello, tre rami: trunk, branches e tags

SVN – Docs

Introduzione ai DVCS (1/2)

I sistemi di revisione distribuiti (DVCS) sono la più recente evoluzione nell’ambito dei sistemi di revisione del codice.

I DVCS nascono per superare alcune limitazioni dei sistemi di revisione classici (basati su un architettura client-server) ma soprattutto per consentire dei workflow più adeguati alle modalità di sviluppo di software complessi (e alle complesse interazioni sul codice che avvengono nello sviluppo di software libero)

Introduzione ai DVCS (2/2)

• 1997: Code Co-op (Reliable Software)
• 2000: BitKeeper (BitMover Inc.)
• 2001: Tom Lord inizia lo sviluppo di quello che sarà GNU arch (e nello stesso periodo inizia lo sviluppo di Monotone)
• 2002: Linus Torvalds decide di utilizzare BitKeeper per lo sviluppo del kernel Linux
• 2002: David Roundy inizia lo sviluppo di DARCS
• 2004: Robert Collins (Canonical Ltd.) annunca Baz (un fork di GNU arch)
• 2005: Martin Pool (Canonical Ltd.) inizia lo sviluppo di Bazaar
• 2005: BitMover Inc. ritira le licenze d’uso agli sviluppatori del kernel Linux accusando Andrew Tridgell di avere effettuato reverse engineering (espressamente vietato dalla licenza d’uso)
• 2005: Linus Torvalds inizia lo sviluppo di GIT, lo annuncia e e lo porta allo stato di self-hosting e hosting dei sorgenti del kernel Linux
• 2005: Matt Mackall annuncia lo sviluppo di Mercurial allo scopo di sostituire BitKeeper nel mantenimento dei sorgenti del kernel Linux

Il modello a Bazaar

<<Nel modello a Bazaar il codice sorgente della revisione in sviluppo è disponibile liberamente, gli utenti possono interagire con gli sviluppatori e se ne hanno le capacità possono modificare e integrare il codice. Lo sviluppo è decentralizzato e non esiste una rigida suddivisione dei compiti: un programmatore di buona volontà può modificare e integrare qualsiasi parte del codice. In sostanza lo sviluppo è molto più anarchico e libero, da qui il nome di modello a Bazaar. Il Kernel Linux e molti programmi utilizzano questo nuovo modello di sviluppo associativo.>>

Wikipedia

Bazaar: un DVCS libero (1/2)

Bazaar è un sistema di revisione decentralizzato multipiattaforma.

Le sue principali caratteristiche sono:

Merging intelligente

• riconosce e unisce solo le parti di codice mancanti;
• minimizza i conflitti tra le parti unite;
• non viene “confuso” da cambiamenti identici;

Facile da usare

• basta conoscere pochi comandi per essere produttivi da subito;
• il numero complessivo di comandi non supera la dozzina;
• ad ogni comando e’ associato un aiuto dettagliato;

Intuitivo

• si possono gestire i branch utilizzando i comandi del SO (rm, cp, mv, etc…);
• per ogni comando esistono degli alias che facilitano l’uso di bzr agli utenti cvs;

Bazaar: un DVCS libero (2/2)

Molto ben integrato

• esistono molti tool di terze parti che permettono di personalizzare bzr;
• supporta un gran numero di architetture e sistemi operativi;
• supporta nomi di file in formato unicode;

Altamente configurabile

• si possono impostare dei parametri di default per le informazioni personali (es: indirizzo email);
• si possono impostare dei parametri di default per ciascun branch;

Flessibile

• dozzine di plugins disponibili;
• multipiattaforma (supporta persino windows);

Architettura

Terminologia di BZR

• branch: linea di sviluppo di un progetto
• working tree: directory posta sotto il controllo di revisione
• revision: particolare versione del codice sorgente
• commit: creazione di una revisione a partire dalla revisione precedente e lo stato attuale del working tree
• repository: un insieme di revisioni
• tag: nome mnemonico associato ad una revisione
• merge: processo di intersezione tra due branch

Workflow di BZR (1/2)

Workflow di BZR (2/2)

Comandi di base (1/2)

Inizializzazione

• bzr init myproject
• bzr branch url mybranch
• bzr checkout url mycheckout

Manipolazione del filesystem

• bzr add foo.bar
• bzr add foo/
• bzr remove foo.bar
• bzr move foo bar

Controllo delle versioni

• bzr commit
• bzr uncommit
• bzr revert

Comandi di base (2/2)

Merging

• bzr merge from_branch
• bzr pull from_branch
• bzr resolve

Pubblicazione

• bzr push url

Ottenere informazioni

• bzr status
• bzr log
• bzr log -r -1
• bzr log -r 1000.. (visualizza tutte le revisioni dalla millesima in poi)
• bzr log -r ..1000 (visualizza fino alla millesima revisione compresa)
• bzr log -r 1000..1100 (visualizza tutte le revisioni nell’intervallo 1000..1100)
• bzr log -r 1000 (visualizza solo la millesima revisione)

• bzr diff

Risoluzione dei conflitti con bzr (1/3)

Uno strumento di fondamentale importanza messo a disposizione da bzr consiste nell’algoritmo di intersezione delle revisioni (merge).

Supponiamo di aver scaricato il branch di un progetto dal repository pubblico di quest’ultimo e di aver effettuato alcune modifiche.

Mentre noi procedevamo con l’implementazione nella nostra copia locale, e’ plausibile che nel frattempo qualcun altro abbia contribuito allo sviluppo del progetto pubblicando alcuni cambiamenti nel repository ufficiale.

Risoluzione dei conflitti con bzr (2/3)

Le modifiche effettuate su entrambi i branch segnano un punto di divergenza tra il repository pubblico e il nostro working tree locale. Ora supponiamo di voler unire questi due branch. In particolare, vogliamo “fondere” il branch pubblico sul nostro branch locale.

Ci affidiamo quindi al comando merge:

# bzr merge

Risoluzione dei conflitti con bzr (3/3)

Se l’algoritmo di merging non incontra conflitti durante la fase di fusione delle versioni allora non è richiesto alcun intervento da parte dello sviluppatore e si può precedere al commit:

# bzr commit

In caso di conflitto bzr aggiunge al nostro working tree tre file secondo il seguente schema:

nomefile.BASE, nomefile.THIS, nomefile.OTHER

Tali file rappresentano rispettivamente la base comune prima del verificarsi della divergenza, il file presente sulla nostra working copy, il file presente sul branch da cui abbiamo effettuato il merge (il branch remoto).

Inoltre, nel file oggetto del conflitto, mediante una sintassi particolare, viene identificato il punto in cui si è verificata la divergenza tra le revisioni.

Prima interazione con bzr

# bzr init myproject
# bzr add somefile
# bzr commit -m 'primo commit'
# modifica al working tree
# bzr status
# bzr commit -m 'commit delle modifiche'
# bzr status

Branching, Merging e Tagging… (1/2)

Come abbiamo visto, una branch è una linea di sviluppo di un progetto.

Il processo di branching consiste nel clonare una branch esistente in modo da proseguire uno sviluppo autonomo locale.

Il processo di fusione tra due branch si dice merging.

Il processo di tagging consiste nell’assegnare un nome ad una particolare revisione.

Branching, Merging e Tagging… (2/2)

# bzr branch url_repository
# bzr log
# modifica al working tree
# bzr status
# bzr commit -m 'descrizione della modifica'
# bzr missing
# bzr merge
# bzr diff
# bzr commit -m 'descrizione del merge'
# bzr tag nome_revisione

Accedere ad un repository remoto (1/2)

bazaar supporta molteplici modalità di interazione con i repository remoti. I protocolli attualmente supportati sono:

• ftp (prefisso url: ftp://)
• bzr smart server (prefisso url: bzr://)
• bzr+ssh (prefisso url: bzr+ssh://)
• sftp (prefisso url: sftp://)
• http (prefisso url: http://)
• https (prefisso url: https://)

Accedere ad un repository remoto (2/2)

Supponiamo di voler clonare il branch di sviluppo del progetto bazaar. Il comando da eseguire è il seguente:

# bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev

In questo caso il protocollo di trasmissione utilizzato è il classico http.

Bazaar – Docs