PROFILBARU.COM

Il controllo versione (in inglese version control), 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 o documentali gestiti da un team collaborativo di sviluppo o redazione.^[1]

Viene dunque usato prevalentemente nello sviluppo di progetti ingegneristici o informatici per gestire la continua evoluzione dei documenti digitali come i disegni tecnici, il codice sorgente del software, la documentazione testuale e altre informazioni importanti su cui può lavorare una squadra di persone (la cronologia di Wikipedia è un esempio a tutti gli effetti di sistema di controllo versione).

Descrizione

Caratteristiche

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 a 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 a 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ù sofisticati 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 a 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 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 a 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 in locale, 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.

Programmi e sistemi utilizzati

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 o Subversion (SVN), 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 un'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

Repository: il repository è l'archivio dove i file sono memorizzati, spesso su file server. Talvolta è chiamato anche depot (ad esempio dal software Perforce).
Check-in: un check-in (o ci o, più raramente, install, submit) 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). Il check-in è l'inserimento del file nonché lo stato corrispondente.
Modifica: una modifica (change) rappresenta una specifica modifica a 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). Il check-out è il prelievo del file nonché lo stato corrispondente.
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 a un check-out ma 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 a 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.
Vaulting: complesso di azioni che regola l'inserimento (check-in) e il prelievo (check-out), da parte di un client, del contenuto documentale di un'unità d'informazione (oggetto) controllata dall'application server^[2]. Il vaulting logico si differenzia dal vaulting fisico che è lo spostamento dei byte che costituiscono il file relativo all'oggetto. Lo spostamento avviene nel vault (zona di memorizzazione) controllato dal file server.

Note

^ 1.1 Per Iniziare - Il Controllo di Versione, su git-scm.com. URL consultato il 17 agosto 2022.
^ L'application server gestisce la logica del sistema e le interazioni con il file server.