Controllo versione

Da Wikipedia, l'enciclopedia libera.
Esempio dell'albero della cronologia di un progetto sotto controllo di versione

Il controllo versione (versioning), in informatica, è la gestione di versioni multiple di un insieme di informazioni.

Gli strumenti software per il controllo versione sono ritenuti molto spesso necessari per la maggior parte dei progetti di sviluppo software. La cronologia di Wikipedia è un esempio di sistema di controllo versione.

Caratteristiche[modifica | modifica wikitesto]

Il controllo versione ingegneristico si è sviluppato dai processi formali basati sui disegni cartacei. 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 progetto. Quando viene apportata la prima modifica, il numero identificativo di versione passa a 2 e così via.

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 prodotti da ciascun sviluppatore, condividendone allo stesso tempo la versione più aggiornata o modificata da ciascuno mostrando dunque in tempi brevi lo stato di avanzamento del lavoro di sviluppo. 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 è verificato. 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 conservare una copia per ogni diversa versione del software, e identificarle appropriatamente. Questo approccio è stato usato in molti grandi progetti software. Sebbene questo metodo possa funzionare, è inefficiente (dato che verranno 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.

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. La maggior parte dei sistemi di controllo versione possono risolvere questo problema in due diversi modi. Questo problema riguarda solamente i sistemi di controllo versione centralizzati, poiché i sistemi distribuiti permettono intrinsecamente più modifiche simultanee.

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.

Utilizzo[modifica | modifica wikitesto]

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.

Programmi e sistemi utilizzati[modifica | modifica wikitesto]

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.

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, certi 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 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. 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.

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.

Glossario[modifica | modifica wikitesto]

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 del repository (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 di 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 inversa dell'importazione).
Update
Un update (o sync) copia le modifiche fatte sul repository nella propria directory di lavoro (può essere visto come l'operazione inversa del 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 in contemporanea allo stesso documento non vedendo l'uno le modifiche che sta apportando l'altro e che potrebbero sovrapporsi. 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.

Voci correlate[modifica | modifica wikitesto]

informatica Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica