Repository 32bit  Forum
Repository 64bit  Wiki

Breve introduzione a CVS

Da Slacky.eu.
Versione delle 07:50, 9 set 2006, autore: Slacky (Discussione | contributi)

(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)

In questo breve articolo viene presentato il sistema di controllo delle versioni CVS (Concurrent Versions System) ed il suo front-end per KDE, Cervisia.

Introduzione al problema

Quando un programmatore sviluppa un software di discrete dimensioni, spesso, si trova a dover affrontare tutta una serie di problemi che non hanno direttamente a che fare con il software oggetto di sviluppo. Vediamone alcuni esempi nel particolare.
Immaginiamo, ad esempio, un programmatore alle prese con un software perfettamente funzionante. Nel caso in cui una importante modifica al codice, necessaria per poter aggiungere una nuova feature, renda il programma non più in grado di funzionare oppure crei un pericoloso bug, la possibilità di tenere traccia di tutte le modifiche effettuate e di poter ritornare ad una versione priva di problemi risulterebbe piuttosto utile.
Dobbiamo poi notare che, in generale, nessun software di discrete dimensioni viene sviluppato da un singolo programmatore ma, più realisticamente, da un team composto da più persone che possono anche lavorare in luoghi e tempi diversi. Con queste premesse si deve tener conto quindi anche dei noti problemi che il settore definito computer-supported cooperative work (CSCW) tenta di risolvere, come, ad esempio, la gestione di modifiche effettuate contemporaneamente ad uno stesso file da parte di due programmatori differenti.
L’obiettivo di un sistema di controllo delle versioni è proprio quello di permettere ad una o più persone di lavorare ad uno stesso progetto in maniera semplice ed efficace riducendo al minimo il carico organizzativo necessario.

I primi passi

Un primo tentativo di risolvere questi problemi prevede l’utilizzo del tool Unix [www.gnu.org/software/diffutils/diffutils.html diff] in combinazione con il programma sviluppato da Larry Wall, [www.gnu.org/software/patch/patch.html patch]. diff è stato pensato per permettere il confronto di due file simili (F1 e F2) e restituire in output una lista (d) con le differenze riscontrate (diff : F2 − F1 = d). Sulla base di questo output, poi, patch è in grado di modificare il file originale (F1) andando ad inserire le modifiche e creando così una versione (F2) cosiddetta "patched" (patch : F2 = F1 + d).
Sebbene questa soluzione renda più semplice incorporare numerose modifiche effettuate da diversi programmatori su un singolo progetto, essa è ancora priva della capacità di tenere traccia della project’s history. Nell’eventualità, infatti, che una modifica debba essere eliminata dal codice, anche nel caso ottimistico in cui il programmatore sappia quale patch ha prodotto le modifiche, l’eliminazione manuale è comunque un processo noioso e destinato a produrre errori. Un passo avanti nella gestione di progetti software si ha con il programma sviluppato da Walter Tichy Revision Control System (RCS)4 nel 1982 che mantiene, per ogni file, i dati storici ad esso relativi. I vantaggi però finiscono qui. RCS, infatti, è privo di numerose features quali la possibilità di lavorare utilizzando una rete, questo obbliga gli sviluppatori a lavorare alla stessa macchina su cui vengono salvati i dati storici del progetto oppure ad avvalersi di script che mantengano aggiornato il server RCS. In questo software manca inoltre l’idea stessa di progetto, ogni file infatti viene gestito singolarmente e non ci sono relazioni tra file nemmeno se questi si trovano nella stessa directory. Il problema maggiore però deriva dallo stile di sviluppo basato sul modello “lock-modify-unlock”. In questo modo uno sviluppatore che desideri lavorare su un file deve prima assicurarsi dei diritti di scrittura esclusivi per quel file (un lock), in modo che nessun altro possa modificarlo contemporaneamente, effettuare le modifiche e rilasciare il file (unlock). Con questo modello si rende necessaria una negoziazione tra gli sviluppatori per decidere chi possa lavorare o meno sul file in questione, con lo spiacevole imprevisto che, se un programmatore dimentica di sbloccare il file, l’unico modo per gli altri di lavorare è quello di “rubargli il lock”.

Articolo in fase di trascrizione

Loris 08:50, 9 Set 2006 (CEST)

Strumenti personali
Namespace

Varianti