Repository 32bit  Forum
Repository 64bit  Wiki

Breve introduzione a CVS: differenze tra le versioni

Da Slacky.eu.
 
Riga 10: Riga 10:
== I primi passi ==
== 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
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)'''.<br>
+
''(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)''.<br>
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à,
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
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
Riga 16: Riga 16:
di “rubargli il lock”.
di “rubargli il lock”.
Articolo in fase di trascrizione
+
== Lo sviluppo open source ==
  +
In un contesto classico di sviluppo del software, basato cioè su un’unica azienda al cui interno lavorino tutti i programmatori associati al progetto, l’uso di RCS è possibile anche se si rende necessario organizzare il lavoro
  +
del team di sviluppo in maniera molto precisa per evitare “sovrapposizioni di modifiche”.<br>
  +
Con il crescere del movimento open source, però, i problemi non risolti da RCS vengono percepiti in maniera molto più pesante. Lo sviluppo di un software open source, infatti, prevede il contributo di un numero estremamente elevato di programmatori sparsi in tutto il pianeta. In questo contesto appare chiaro come il modello “lock-modify-unlock” fallisca. Evidentemente non è possibile coordinare un gruppo di sviluppatori se nemmeno si conoscono i membri che in un dato momento lavorano al progetto, e non è nemmeno pensabile, dato il gran numero di persone coinvolte, permettere
  +
la modifica di un file ad un solo programmatore alla volta.
  +
  +
== Una soluzione: CVS ==
  +
Nel 1986, Dick Grune, ha dato il via al progetto CVS (Concurrent Versions System) con l’intento di risolvere i problemi lasciati aperti da RCS. In origine CVS era una collezione di script, riscritti in linguaggio C da Brian
  +
Berliner nel 1989, basati sul formato di salvataggio dei dati storici di RCS.<br>
  +
I miglioramenti più evidenti riguardano:
  +
* la possibilità di gestire un progetto come un’unica entità;
  +
* il networking;
  +
* l’abbandono del modello "lock-modify-unlock" in favore del migliore "copy-modify-merge".<br>
  +
A differenza di RCS, che gestisce ogni singolo file come entità autonoma, CVS fornisce la possibilità di associare ad un progetto un insieme di directory e file. In questo modo è possibile gestire il progetto come una singola entità a cui applicare i comandi di gestione. Nel 1990, Jim Kingdon, ha aggiunto a CVS la possibilità di networking. Finalmente gli sviluppatori possono accedere ai file del progetto da ogni parte del mondo sfruttando Internet. Invece di proibire la modifica simultanea di un file costringendo gli sviluppatori ad un’attenta attività di coordinamento, CVS permette di lavorare contemporaneamente sullo stesso file, si incarica di applicare le modifiche apportate e di segnalare eventuali conflitti. Il modello usato è il "copymodify-merge" che possiamo riassumere nei seguenti passi
  +
  +
Articolo in fase di trascrizione
[[Utente:Slacky|Loris]] 08:50, 9 Set 2006 (CEST)
[[Utente:Slacky|Loris]] 08:50, 9 Set 2006 (CEST)

Versione delle 07:58, 9 set 2006

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

Indice

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”.

Lo sviluppo open source

In un contesto classico di sviluppo del software, basato cioè su un’unica azienda al cui interno lavorino tutti i programmatori associati al progetto, l’uso di RCS è possibile anche se si rende necessario organizzare il lavoro del team di sviluppo in maniera molto precisa per evitare “sovrapposizioni di modifiche”.
Con il crescere del movimento open source, però, i problemi non risolti da RCS vengono percepiti in maniera molto più pesante. Lo sviluppo di un software open source, infatti, prevede il contributo di un numero estremamente elevato di programmatori sparsi in tutto il pianeta. In questo contesto appare chiaro come il modello “lock-modify-unlock” fallisca. Evidentemente non è possibile coordinare un gruppo di sviluppatori se nemmeno si conoscono i membri che in un dato momento lavorano al progetto, e non è nemmeno pensabile, dato il gran numero di persone coinvolte, permettere la modifica di un file ad un solo programmatore alla volta.

Una soluzione: CVS

Nel 1986, Dick Grune, ha dato il via al progetto CVS (Concurrent Versions System) con l’intento di risolvere i problemi lasciati aperti da RCS. In origine CVS era una collezione di script, riscritti in linguaggio C da Brian Berliner nel 1989, basati sul formato di salvataggio dei dati storici di RCS.
I miglioramenti più evidenti riguardano:

  • la possibilità di gestire un progetto come un’unica entità;
  • il networking;
  • l’abbandono del modello "lock-modify-unlock" in favore del migliore "copy-modify-merge".

A differenza di RCS, che gestisce ogni singolo file come entità autonoma, CVS fornisce la possibilità di associare ad un progetto un insieme di directory e file. In questo modo è possibile gestire il progetto come una singola entità a cui applicare i comandi di gestione. Nel 1990, Jim Kingdon, ha aggiunto a CVS la possibilità di networking. Finalmente gli sviluppatori possono accedere ai file del progetto da ogni parte del mondo sfruttando Internet. Invece di proibire la modifica simultanea di un file costringendo gli sviluppatori ad un’attenta attività di coordinamento, CVS permette di lavorare contemporaneamente sullo stesso file, si incarica di applicare le modifiche apportate e di segnalare eventuali conflitti. Il modello usato è il "copymodify-merge" che possiamo riassumere nei seguenti passi

Articolo in fase di trascrizione 

Loris 08:50, 9 Set 2006 (CEST)

Strumenti personali
Namespace

Varianti