Controllo versione

Da Wikipedia, l'enciclopedia libera.

In informatica, il controllo versione è la gestione di versioni multiple di un insieme di informazioni.

Viene usato prevalentemente nello sviluppo di progetti ingegneristici o informatici per gestire la continua evoluzione dei documenti digitali come il codice sorgente del software, i disegni tecnici, la documentazione testuale e altre informazioni importanti su cui può lavorare una squadra di persone. Le modifiche a questi documenti sono identificate incrementando un numero o un codice associato ad essi, denominato "numero di versione", "etichetta di versione", o semplicemente "versione", e sono etichettate con il nome della persona che ha apportato la modifica.

Una semplice forma di controllo versione, per esempio, assegna il numero 1 alla prima versione di un disegno. Quando viene apportata la prima modifica, il numero di versione passa a 2 e così via.

Gli strumenti software per il controllo versione sono sempre più riconosciuti essere necessari per la maggior parte dei progetti di sviluppo software.

[modifica] Panoramica

Il controllo versione ingegneristico si è sviluppato dai processi formali basati sui disegni cartacei.

In questo controllo era implicita la possibilità di tornare ad uno stato precedente del progetto, nei casi in cui si raggiungeva un vicolo cieco ingegneristico. Parimenti, nell'ingegneria del software, il controllo versione è qualunque pratica che tiene traccia e permette di controllare i cambiamenti al codice sorgente. Gli sviluppatori software talvolta usano il controllo versione software anche per i file di documentazione e di configurazione, oltre che per il codice sorgente. In teoria, il controllo versione può essere applicato a qualunque tipo di registrazione di informazioni. Tuttavia, in pratica le tecniche e gli strumenti più sofisticate per il controllo versione sono stati usati raramente al di fuori degli ambienti di sviluppo software (sebbene potrebbero effettivamente essere utili in molte altre aree). Comunque, si sta cominciando ad usarli per tener traccia delle modifiche a file di CAD, soppiantando la gestione "manuale" delle versioni.

Man mano che il software viene sviluppato e dispiegato, è sempre più probabile che versioni distinte dello stesso software siano dispiegate in posti diversi, e che gli sviluppatori del software lavorino privatamente allo sviluppo di aggiornamenti. I bug e altre questioni riguardanti il software sono spesso presenti solamente in certe versioni (a causa del fatto che man mano che il software evolve alcuni problemi vengono corretti e altri ne vengono rilevati). Pertanto, allo scopo di individuare e correggere i bug, è di importanza vitale per il programmatore poter recuperare e mandare in esecuzione diverse versioni del software per determinare in quali versioni il problema si verifica. Può anche essere necessario sviluppare parallelamente due versioni del software (quando, per esempio, in una versione sono stati corretti dei bug, ma non ha nuove caratteristiche, mentre nell'altra versione vengono sviluppate le nuove caratteristiche).

Al livello più semplice, gli sviluppatori possono semplicemente conservare una copia per ogni diversa versione del software, e identificarle appropriatamente. Questo semplice approccio è stato usato in molti grandi progetti software. Sebbene questo metodo può funzionare, è inefficiente (dato che verrano conservate molte copie quasi identiche del software), richiede molta disciplina da parte degli sviluppatori, e conduce spesso ad errori. Conseguentemente, sono stati sviluppati dei sistemi per automatizzare (in parte o in toto) il procedimento di controllo versione.

Tradizionalmente, i sistemi di controllo versione hanno usato un modello centralizzato, in cui tutte le funzioni di controllo versione sono eseguite da un server condiviso. Alcuni anni fa, alcuni sistemi, come TeamWare, BitKeeper, e GNU arch hanno cominciato a usare un modello 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 agli sviluppatori di lavorare senza una connessione di rete, e consente anche agli sviluppatori di accedere alle funzioni di controllo versione senza aver bisogno di permessi concessi da un'autorità centrale.

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, gli sviluppatori possono facilmente sovrascrivere o perdere le modifiche effettuate contestualmente. La maggior parte dei sistemi di controllo versione risolvono questo problema in uno di due modi. Questo è un problema solamente per i sistemi di controllo versione centralizzati, siccome i sistemi distribuiti permettono inerentemente più modifiche simultanee.

Alcuni sistemi prevengono i problemi dovuti ad accessi simultanei, semplicemente bloccando (lock) i file, cosicché solamente uno sviluppatore per volta ha diritto di accesso in scrittura alla copia di quel file contenuta nel repository centrale. Altri, come CVS, permettono a più sviluppatori di modificare lo stesso file nello stesso tempo, e forniscono degli strumenti per combinare le modifiche in seguito (merge). In quest'ultimo tipo, può esistere una operazione di blocco facoltativa.

I pregi e i difetti del blocco dei file sono in discussione. Tale operazione può fornire una certa protezione da difficili conflitti di merge quando un utente sta facendo delle modifiche radicali a molte sezioni di un grande file (o di un gruppo di file). Ma se i file sono lasciati bloccati troppo a lungo, gli altri sviluppatori possono essere tentati di scavalcare il software di controllo versione e di modificare comunque i file localmente, e ciò può condurre a problemi più seri.

Alcuni sistemi tentano di gestire i profili di chi ha il permesso di apportare modifiche; per esempio, richiedendo che le modifiche a un file siano approvate da un recensore designato prima di essere aggiunte.

La maggior parte dei sistemi di controllo versione 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.

Alcuni degli strumenti di controllo versione più avanzati offrono molte altre funzionalità, consentendo una più profonda integrazione con altri strumenti e procedimenti di ingegneria del software. Spesso sono disponibili dei plug-in per IDE come Eclipse e Visual Studio.

La cronologia di Wikipedia è un esempio di sistema di controllo versione.

[modifica] Glossario

Repository: Il repository è dove i file sono memorizzati, spesso su un server. Talvolta è chiamato anche depot (ad esempio col software Perforce).
Commit: Un commit (o, più raramente, install, submit, check-in o ci) si effettua quando si copiano le modifiche fatte su file locali nella directory (il software di controllo versione controlla quali file sono stati modificati dall'ultima sincronizzazione).
Modifica: Una modifica (change) rappresenta una specifica modifica ad un documento sottoposto al controllo di versione. La granularità delle modifiche considerate come cambiamenti varia tra i sistemi di controllo versione.
Change List: Su molti sistemi di controllo versione con commit di modifiche multiple atomiche, una changelist' identifica un insieme changes fatti in un singolo commit.
Check-Out: Un check-out (o checkout o co) effettua una copia di lavoro dal repository (può essere visto come l'operazione contraria all'importazione).
Update: Un update (o sync) copia le modifiche fatte sul repository nella propria directory di lavoro (può essere visto come l'operazione contraria al commit).
Merge / Integrazione: Un merge o integrazione unisce modifiche concorrenti in una revisione unificata.
Revisione: Una revisione o versione è una versione in una catena di modifiche.
Import: Il termine import è usato per descrivere la copiatura dell'intero albero di directory locale sul repository.
Export: Un export è simile ad un check-out eccetto il fatto che crea un albero di directory vuoto senza metadati di controllo versione (spesso è usato precedentemente alla pubblicazione dei contenuti).
Conflitto: Un conflitto si presenta quando diversi soggetti fanno modifiche allo stesso documento. Non essendo il software abbastanza intelligente da decidere quale tra le modifiche è quella 'corretta', si richiede ad un utente di risolvere il conflitto.
Risolvere: L'intervento di un utente per la risoluzione di un conflitto tra modifiche differenti di uno stesso documento.