Concurrent Versions System
# Concurrent Versions System

Il Concurrent Versions System (CVS), conosciuto anche come Concurrent Versioning System, è un sistema software, divenuto popolare nel mondo del software libero e distribuito sotto la GNU General Public License, che implementa un sistema di controllo versione.

Il programma mantiene al corrente tutto il lavoro e i cambiamenti operati in un insieme di file, tipicamente l'implementazione di un software in via di sviluppo, permettendo dunque a molti sviluppatori (potenzialmente distanti) di collaborare in team allo sviluppo del codice sorgente accedendo alle medesime risorse disponibili in maniera concorrente ovvero senza creare conflitti nelle modifiche allo stesso software.

## Storia

CVS venne sviluppato da un sistema di controllo versioni chiamato Revision Control System (RCS), ancora in uso, il quale gestisce file individuali ma non l'intero progetto. Dick Grune ha fornito alcune note storiche sul CVS sul suo sito:

«I created CVS to be able to cooperate with my students Erik Baalbergen and Maarten Waage on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.»

«Creai CVS per essere in grado di cooperare con i miei studenti Erik Baalbergen e Maarten Waage sul compilatore C dell ACK (Amsterdam Compiler Kit). Noi tre avevamo orari ampiamente differenti (uno studente era un lavoratore costante dalle 9 alle 17, l'altro era irregolare, e io potevo lavorare sul progetto solo di sera). Il loro progetto funzionò dal luglio del 1984 all'agosto del 1985. CVS fu inizialmente chiamato cmt, per l'ovvio motivo che ci permise di distribuire versioni indipendentemente.»

(Dick Grune, Concurrent Versions System CVS)

Il codice fu pubblicamente distribuito sul newsgroup mod.sources il 23 giugno 1986. Si può ancora vedere il post originale su usenet su Google Groups.

Il codice che finalmente si è evoluto nella versione corrente del CVS iniziata con Brian Berliner nell'aprile 1989, più tardi con l'input di Jeff Polk e molti altri contributori. Brian Berliner scrisse una pagina web che introduce i suoi miglioramenti nel programma CVS il quale descrive come lo strumento fosse esteso e utilizzato internamente da Prisma, uno sviluppatore free lance che lavorava sul kernel di SunOS, e venne distribuito a favore della comunità sotto GPL.

Oggigiorno, un gruppo di volontari gestisce il codice di CVS. Lo sviluppo della versione di CVS per Microsoft Windows si è scisso in un progetto chiamato CVSNT ed è stato considerevolmente più attivo nell'estendere l'insieme delle funzioni del sistema, tanto da effettuare il porting di queste modifiche sulla piattaforma UNIX sotto il nome di CVSNT.

La relazione tra il CVS e il progetto GNU può apparire in qualche modo ambigua: il sito di GNU distribuisce il programma, identificandolo come "GNU package" (pacchetto GNU) su una pagina e "other GPL-licensed project" (altri progetti con licenza GPL) su un'altra. Sul sito FTP, il programma risiede nella directory /non-gnu/.

Un certo numero di sviluppatori chiave che hanno lavorato sul CVS sono ora responsabili del progetto SVN (Subversion), distribuito nella prima metà del 2004, e che mira a sostituire CVS per superare alcune sue limitazioni.

## Terminologia

La terminologia di CVS soprannomina un progetto singolo (insieme dei relativi file) controllato da CVS come un modulo. Un server CVS può controllare molti moduli ed immagazzinare tutti i moduli in un relativo repository. La copia di un modulo che è stato scaricato dal server tramite un client viene chiamata working copy oppure sandbox.

## Caratteristiche

Il CVS utilizza un'architettura tipica di tipo client-server: 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.

Il software del server normalmente gira su Unix (sebbene esista anche un server CVS su Windows NT), mentre i client CVS possono girare su un maggiore numero di sistemi operativi.

## Funzioni

Molti client possono simultaneamente pubblicare le copie dei progetti. Quando essi registrano poi i cambiamenti, il server tenta di fonderli. Se questo sistema fallisce, per esempio perché due client hanno cercato di cambiare la stessa linea in un certo file, 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 nel relativo file di log.

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. Molti progetti open source permettono l'accesso in lettura anonimo ("anonymous read access"), una funzione che era pioniera di OpenBSD. Ciò significa che i client possono verificare e confrontare versioni tramite uno spazio bianco o semplicemente con la password pubblicata (per esempio "anoncvs"); solo per la registrazione di un cambiamento si richiede un account personale ed una password.

I client possono anche 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 può anche mantenere diversi "rami" (branch, plurale branches) di un progetto. Per esempio, una versione distribuita del progetto può formare una branch, utilizzata per riparare bug, mentre una versione sotto lo sviluppo corrente, con maggiori cambiamenti e nuove funzioni, forma una branch separata. Utilizza la compressione delta per un efficiente immagazzinamento delle diverse versioni dello stesso file.

