Cos’è il "controllo di versione", e perché dovresti usarlo? Il controllo di versione è un sistema che registra, nel tempo, i cambiamenti ad un file o ad una serie di file, così da poter richiamare una specifica versione in un secondo momento. Per gli esempi di questo libro verrà usato il codice sorgente di un software come file sotto controllo di versione, anche se in realtà gli esempi si possono eseguire quasi con ogni tipo di file sul computer.
Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un’immagine o di un layout (cosa che sicuramente vorresti), un Sistema per il Controllo di Versione (VCS) è una cosa saggia da utilizzare. Un VCS ti permette di ripristinare i file ad una versione precedente, ripristinare l’intero progetto a uno stato precedente, revisionare le modifiche fatte nel tempo, vedere chi ha cambiato qualcosa che può aver causato un problema, chi ha introdotto un problema e quando, e molto altro ancora. Usare un VCS, in generale, significa anche che se fai un pasticcio o perdi qualche file, puoi facilmente recuperare la situazione. E ottieni tutto questo con poca fatica.
Molte persone gestiscono le diverse versioni copiando i file in un’altra directory (magari una directory denominata con la data, se sono furbi). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. É facile dimenticare in quale directory sei e modificare il file sbagliato o copiare dei file che non intendevi copiare.
Per far fronte a questo problema, i programmatori svilupparono VCS locali che avevano un database semplice che manteneva tutti i cambiamenti dei file sotto controllo di revisione.
Uno dei più popolari strumenti VCS era un sistema chiamato RCS, che è ancora oggi distribuito con molti computer. RCS funziona salvando sul disco in un formato specifico un insieme di patch (ovvero le differenze tra i file); può quindi ricreare lo stato di qualsiasi file in qualsiasi momento determinato, aggiungendo le varie patch.
Successivamente queste persone dovettero affrontare il problema del collaborare con altri sviluppatori su altri sistemi. Per far fronte a questo problema, vennero sviluppati sistemi di controllo di versione centralizzati (CVCS). Questi sistemi (come CVS, Subversion e Perforce) hanno un unico server che contiene tutte le versioni dei file e un numero di utenti che scaricano i file dal server centrale. Questo è stato lo standard del controllo di versione per molti anni.
Questa impostazione offre molti vantaggi, specialmente rispetto ai VCS locali. Per esempio, chiunque sa, con una certa approssimazione, cosa stia facendo un’altra persona del progetto. Gli amministratori hanno un controllo preciso su chi può fare cosa, ed è molto più facile amministrare un CVCS 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 questo va giù per un’ora, in quel periodo nessuno può collaborare o salvare una nuova versione di qualsiasi cosa su cui sta lavorando. Se il disco rigido del database centrale si danneggia, e non ci sono i backup, perdi assolutamente tutto — tutta la storia del progetto ad eccezione dei singoli snapshot (istantanee) che le persone possono avere in locale sulle loro macchine. Anche i sistemi locali di VCS soffrono di questo problema — ogni volta che tutta la storia del progetto è in un unico posto, si rischia di perdere tutto.
E qui entrano in gioco i Sistemi di Controllo di Versione Distribuiti (DVCS). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i client non solo controllano lo snapshot più recente dei file, ma piuttosto fanno una copia identica dell’archivio (repository), completa di tutta la propria storia. In questo modo se un server smettesse di funzionare e se i sistemi interagissero tramite questo server, il repository di un qualsiasi client potrebbe essere copiato sul server per ripristinarlo. Ogni clone è proprio un backup completo di tutti i dati.
Inoltre, molti di questi sistemi trattano bene l’avere più repository remoti su cui poter lavorare, così puoi collaborare con gruppi differenti di persone in modi differenti, simultaneamente sullo stesso progetto. Questo ti permette di impostare diversi tipi di flussi di lavoro che non sono possibili in sistemi centralizzati, come i modelli gerarchici.