Repository 32bit  Forum
Repository 64bit  Wiki

Breve introduzione a CVS: differenze tra le versioni

Da Slacky.eu.
Riga 9: Riga 9:
== 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 [http://www.gnu.org/software/diffutils/diffutils.html diff] in combinazione con il programma sviluppato da Larry Wall, [http://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à,
Riga 29: Riga 29:
* il networking;
* il networking;
* l’abbandono del modello "lock-modify-unlock" in favore del migliore "copy-modify-merge".<br>
* 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
+
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.
  +
# Lo sviluppatore (A) scarica una copia del progetto, definita working copy, dal server CVS (repository). Questa azione prende il nome di check out.
  +
# Applica liberamente tutte le modifiche al progetto. Nello stesso tempo altri programmatori potrebbero fare lo stesso (B).
  +
# Terminato il lavoro il programmatore (A) aggiorna il progetto contenuto nel server CVS. In questo caso si parla di commit oppure, alternativamente, check in.
  +
# Nel frattempo altri programmatori (B) potrebbero richiedere a CVS le modifiche al progetto non presenti nella loro working copy oppure l’ultima versione disponibile (C). CVS scaricherà o aggiornerà automaticamente (update) i file in questione.<br>
  +
[[Immagine:cvs.png]]
  +
Nel caso in cui due programmatori modifichino un file nello stesso punto, cioè vengano modificate le stesse linee di codice, CVS se ne accorge e, al tempo del commit o dell’update, notifica il conflitto (conflict). La soluzione
  +
dei conflitti viene comunque lasciata ai programmatori coinvolti. Dando uno sguardo più approfondito si può notare come, vista la necessità di CVS di tenere traccia di tutte le modifiche al progetto fin dal suo inizio, queste vengano salvate internamente come una sequenza di diffs. Grazie a questo accorgimento CVS è in grado di ricostruire ogni versione precedente del progetto applicando a rovescio le modifiche. Sebbene un sistema di gestione delle versioni dia i maggiori vantaggi se usato per lo sviluppo di un progetto da parte di un team composto da numerose persone, ci sono buoni motivi perchè venga utilizzato anche per progetti sviluppati da un singolo programmatore. Oltre alla facilità di applicare o togliere modifiche ad un progetto si può anche citare l’evidente risparmio di spazio su disco. Così facendo infatti non si rende più necessario copiare più volte l’intero progetto per mantenerne diverse versioni. Un sistema di gestione delle revisioni rende inoltre più semplice la creazione di documenti riguardanti lo stato delle modifiche effettuate sul progetto (ad esempio i ChangeLog). Il numero di progetti sviluppati utilizzando CVS è sicuramente molto elevato e, tra di essi, possiamo ricordare a titolo di esempio il server Web Apache, i sistemi operativi FreeBSD, OpenBSD e NetBSD, il desktop manager Gnome e il database PostreSQL.
Articolo in fase di trascrizione
+
= CVS in pratica =
  +
Nella seguente sezione verrà presentata la procedura di installazione del software a partire dai sorgenti. Verrà inoltre presentata l’interfaccia grafica Cervisia che attualmente è un’applicazione ufficiale del desktop manager
  +
KDE.
[[Utente:Slacky|Loris]] 08:50, 9 Set 2006 (CEST)
+
== Installazione ==
  +
=== CVS ===
  +
Come prima cosa è necessario procurarsi i sorgenti della versione che si desidera installare, il sito di riferimento per il progetto CVS è http://www.cvshome.org, in cui si può trovare l’ultima versione stabile del programma.<br>
  +
Al momento della scrittura di questa relazione è la versione 1.11.18 contenuta nel file cvs-1.11.18.tar.bz2. Terminato il download decomprimiamo l’archivio così ottenuto con il classico comando:
  +
root# tar xvfj cvs-1.11.18.tar.bz2
  +
e, nel caso non si siano verificati errori, sul nostro disco troviamo una directory chiamata cvs-1.11.18. Per cominciare la fase di installazione vera e propria portiamoci all’interno della directory appena creata:
  +
root# cd cvs-1.11.18
  +
ed utilizziamo il comando
  +
root#./configure --help
  +
per avere un elenco delle possibili opzioni passabili allo script di configurazione. Per installare CVS nella directory /opt/cvs/ digitiamo i seguenti comandi:
  +
root#./configure --prefix=/opt/cvs/ && make
  +
e, come utente root,
  +
root# make install
  +
A questo punto possiamo inserire la directory /opt/cvs/bin nel $PATH oppure linkare gli eseguibili in una directory già contenuta in esso come nel seguente esempio:
  +
root# ln -s /opt/cvs/bin/cvs /usr/local/bin/cvs
  +
root# ln -s /opt/cvs/bin/cvsbug /usr/local/bin/cvsbug
  +
root# ln -s /opt/cvs/bin/rcs2log /usr/local/bin/rcs2log
  +
Per avere a disposizione anche le “man pages” e il manuale “info” questi sono i comandi da eseguire:
  +
root# ln -s /opt/cvs/man/man1/cvs.1 /usr/local/man/man1/cvs.1
  +
root# ln -s /opt/cvs/man/man5/cvs.5 /usr/local/man/man5/cvs.5
  +
root# ln -s /opt/cvs/man/man8/cvsbug.8 /usr/local/man/man8/cvsbug.8
  +
root# ln -s /opt/cvs/info/cvs* /usr/local/info/.
  +
root# cat /opt/cvs/info/dir >> /usr/info/dir
  +
  +
=== Cervisia ===
  +
Cervisia è una GUI per CVS sviluppata all’interno del progetto KDE e quindi di norma viene installata assieme al desktop manager. Nel caso manchi, basterà installare il pacchetto kdesdk dai sorgenti con il classico:
  +
root#./configure && make && make install
  +
Cervisia è un front-end grafico di CVS “lato client” e quindi non permette di impostare gli aspetti di configurazione di un server CVS, argomento del prossimo paragrafo.
  +
  +
== Configurazione ==
  +
Se siamo interessati soltanto allo sviluppo di un progetto già mantenuto su un server CVS, non dobbiamo fare alcuna configurazione; se invece desideriamo utilizzare CVS per lo sviluppo dei nostri progetti è necessario configurare CVS affinchè operi da server.<br>
  +
Di seguito verrà presentata, per semplicità, la configurazione di un server CVS per un singolo utente/sviluppatore (nel caso in cui si volgiano aggiungere altri utenti questo non crea particolari problemi oltre al tempo necessario per farlo materialmente). Viene inoltre configurato l’utente anonimo in modo tale da permettere a chiunque disponga di una connessione al nostro server di scaricare il progetto che stiamo sviluppando. Il primo passo è quello di creare un repository in questo modo:
  +
root# mkdir /usr/local/cvsrepos
  +
root# cvs -d /usr/local/cvsrepos/ init
  +
così facendo CVS crea automaticamente la directory CVSROOT all’interno
  +
di /usr/local/cvsrepos/, tale directory contiene file necessari a
  +
CVS per il corretto funzionamento. Per problemi di sicurezza è fortemente
  +
consigliato creare un gruppo cvs:
  +
root#groupadd cvs
  +
a cui aggiungere gli utenti che hanno necessità di accedere al repository. Ecco come appare la corrispondente linea nel file /etc/group con
  +
l’elenco di utenti abilitati (è probabile che ci siano piccole differenze oltre
  +
ovviamente ai nomi degli utenti):
  +
cvs:*:504:slack,anonymous
  +
L’ultimo passo consiste nell’assegnare al repository i permessi corretti in
  +
modo che riflettano questi cambiamenti:
  +
root#cd /usr/local/
  +
root#chgrp -R cvs cvsrepos/
  +
root#chmod -R ug+rwx cvsrepos/
  +
a questo punto tutti gli utenti elencati nel gruppo cvs possono iniziare un nuovo progetto nel nostro repository.
  +
Per permettere l’accesso al repository via rete ad utenti privi di un account locale è necessario configurare il password-authenticating server, il servizio si rende indispensabile nel caso si desideri permettere gli accessi
  +
anonimi.
  +
  +
=== Password-Authenticating server ===
  +
Per prima cosa bisogna accertarsi che nel file /etc/services sia presente un riga come questa:
  +
cvspserver 2401/tcp
  +
che ha il compito di associare il password-authenticating server di CVS alla porta 2401. A questo punto bisogna informare l’Unix Internet Daemon (inetd) su come gestire una richiesta di connessione per il servizio cvspserver, modifichiamo quindi il file /etc/inetd.conf aggiungendo la seguente riga:
  +
cvspserver stream tcp nowait root /usr/local/bin/cvs \
  +
cvs --allow-root=/usr/local/cvsrepos pserver
  +
e riavviamo il demone inetd. Adesso è il turno degli utenti, creiamo il file /usr/local/cvsrepos/CVSROOT/passwd ed inseriamo gli utenti desiderati come nell’esempio:
  +
slackcvs:$1$WuA/mI/0$7XO16pEouKtVlwPylKShr0:slack
  +
anonymous:$1$.Gs0DG/0$KeNxi291fp264R1SHOcT5/
  +
il formato del file è molto semplice e prevede il seguente schema:
  +
<NOME_UTENTE>:<PASSWORD_CRITTATA6>:[UTENTE_DEL_SISTEMA]
  +
dove UTENTE_DEL_SISTEMA è opzionale ed è un login valido sul server CVS, dobbiamo fare attenzione che in /etc/passwd sia presente un utente anonymous:
  +
anonymous:x:1006:100:Anonymous CVS User,,,:/usr/local/cvsrepos/:/bin/false
  +
L’ultimo passo consiste nel creare i file readers e writers nella directory /usr/local/cvsrepos/CVSROOT/ nei quali inserire la lista degli utenti a cui concedere il diritto di sola lettura o di lettura-scrittura. Ovviamente il file readers conterrà almeno l’utente anomimo:
  +
root# cat readers
  +
anonymous
  +
mentre writers conterrà l’altro utente che abbiamo impostato in /usr/local/cvsrepos/CVSROOT/passwd:
  +
root# cat writers
  +
slackcvs
  +
si noti come sia indispensabile una linea vuota al termine di questi file. La configurazione del server CVS è conclusa, ora possiamo iniziare lo sviluppo.
  +
  +
== Uso ==
  +
=== Iniziare un nuovo progetto ===
  +
  +
  +
[[Utente:Arjuda|Arjuna Del Toso]]

Versione delle 18:40, 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 diff in combinazione con il programma sviluppato da Larry Wall, 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.

  1. Lo sviluppatore (A) scarica una copia del progetto, definita working copy, dal server CVS (repository). Questa azione prende il nome di check out.
  2. Applica liberamente tutte le modifiche al progetto. Nello stesso tempo altri programmatori potrebbero fare lo stesso (B).
  3. Terminato il lavoro il programmatore (A) aggiorna il progetto contenuto nel server CVS. In questo caso si parla di commit oppure, alternativamente, check in.
  4. Nel frattempo altri programmatori (B) potrebbero richiedere a CVS le modifiche al progetto non presenti nella loro working copy oppure l’ultima versione disponibile (C). CVS scaricherà o aggiornerà automaticamente (update) i file in questione.

Cvs.png Nel caso in cui due programmatori modifichino un file nello stesso punto, cioè vengano modificate le stesse linee di codice, CVS se ne accorge e, al tempo del commit o dell’update, notifica il conflitto (conflict). La soluzione dei conflitti viene comunque lasciata ai programmatori coinvolti. Dando uno sguardo più approfondito si può notare come, vista la necessità di CVS di tenere traccia di tutte le modifiche al progetto fin dal suo inizio, queste vengano salvate internamente come una sequenza di diffs. Grazie a questo accorgimento CVS è in grado di ricostruire ogni versione precedente del progetto applicando a rovescio le modifiche. Sebbene un sistema di gestione delle versioni dia i maggiori vantaggi se usato per lo sviluppo di un progetto da parte di un team composto da numerose persone, ci sono buoni motivi perchè venga utilizzato anche per progetti sviluppati da un singolo programmatore. Oltre alla facilità di applicare o togliere modifiche ad un progetto si può anche citare l’evidente risparmio di spazio su disco. Così facendo infatti non si rende più necessario copiare più volte l’intero progetto per mantenerne diverse versioni. Un sistema di gestione delle revisioni rende inoltre più semplice la creazione di documenti riguardanti lo stato delle modifiche effettuate sul progetto (ad esempio i ChangeLog). Il numero di progetti sviluppati utilizzando CVS è sicuramente molto elevato e, tra di essi, possiamo ricordare a titolo di esempio il server Web Apache, i sistemi operativi FreeBSD, OpenBSD e NetBSD, il desktop manager Gnome e il database PostreSQL.

CVS in pratica

Nella seguente sezione verrà presentata la procedura di installazione del software a partire dai sorgenti. Verrà inoltre presentata l’interfaccia grafica Cervisia che attualmente è un’applicazione ufficiale del desktop manager KDE.

Installazione

CVS

Come prima cosa è necessario procurarsi i sorgenti della versione che si desidera installare, il sito di riferimento per il progetto CVS è http://www.cvshome.org, in cui si può trovare l’ultima versione stabile del programma.
Al momento della scrittura di questa relazione è la versione 1.11.18 contenuta nel file cvs-1.11.18.tar.bz2. Terminato il download decomprimiamo l’archivio così ottenuto con il classico comando:

root# tar xvfj cvs-1.11.18.tar.bz2

e, nel caso non si siano verificati errori, sul nostro disco troviamo una directory chiamata cvs-1.11.18. Per cominciare la fase di installazione vera e propria portiamoci all’interno della directory appena creata:

root# cd cvs-1.11.18

ed utilizziamo il comando

root#./configure --help

per avere un elenco delle possibili opzioni passabili allo script di configurazione. Per installare CVS nella directory /opt/cvs/ digitiamo i seguenti comandi:

root#./configure --prefix=/opt/cvs/ && make

e, come utente root,

root# make install

A questo punto possiamo inserire la directory /opt/cvs/bin nel $PATH oppure linkare gli eseguibili in una directory già contenuta in esso come nel seguente esempio:

root# ln -s /opt/cvs/bin/cvs /usr/local/bin/cvs
root# ln -s /opt/cvs/bin/cvsbug /usr/local/bin/cvsbug
root# ln -s /opt/cvs/bin/rcs2log /usr/local/bin/rcs2log

Per avere a disposizione anche le “man pages” e il manuale “info” questi sono i comandi da eseguire:

root# ln -s /opt/cvs/man/man1/cvs.1 /usr/local/man/man1/cvs.1
root# ln -s /opt/cvs/man/man5/cvs.5 /usr/local/man/man5/cvs.5
root# ln -s /opt/cvs/man/man8/cvsbug.8 /usr/local/man/man8/cvsbug.8
root# ln -s /opt/cvs/info/cvs* /usr/local/info/.
root# cat /opt/cvs/info/dir >> /usr/info/dir

Cervisia

Cervisia è una GUI per CVS sviluppata all’interno del progetto KDE e quindi di norma viene installata assieme al desktop manager. Nel caso manchi, basterà installare il pacchetto kdesdk dai sorgenti con il classico:

root#./configure && make && make install

Cervisia è un front-end grafico di CVS “lato client” e quindi non permette di impostare gli aspetti di configurazione di un server CVS, argomento del prossimo paragrafo.

Configurazione

Se siamo interessati soltanto allo sviluppo di un progetto già mantenuto su un server CVS, non dobbiamo fare alcuna configurazione; se invece desideriamo utilizzare CVS per lo sviluppo dei nostri progetti è necessario configurare CVS affinchè operi da server.
Di seguito verrà presentata, per semplicità, la configurazione di un server CVS per un singolo utente/sviluppatore (nel caso in cui si volgiano aggiungere altri utenti questo non crea particolari problemi oltre al tempo necessario per farlo materialmente). Viene inoltre configurato l’utente anonimo in modo tale da permettere a chiunque disponga di una connessione al nostro server di scaricare il progetto che stiamo sviluppando. Il primo passo è quello di creare un repository in questo modo:

root# mkdir /usr/local/cvsrepos
root# cvs -d /usr/local/cvsrepos/ init

così facendo CVS crea automaticamente la directory CVSROOT all’interno di /usr/local/cvsrepos/, tale directory contiene file necessari a CVS per il corretto funzionamento. Per problemi di sicurezza è fortemente consigliato creare un gruppo cvs: root#groupadd cvs a cui aggiungere gli utenti che hanno necessità di accedere al repository. Ecco come appare la corrispondente linea nel file /etc/group con l’elenco di utenti abilitati (è probabile che ci siano piccole differenze oltre ovviamente ai nomi degli utenti): cvs:*:504:slack,anonymous L’ultimo passo consiste nell’assegnare al repository i permessi corretti in modo che riflettano questi cambiamenti: root#cd /usr/local/ root#chgrp -R cvs cvsrepos/ root#chmod -R ug+rwx cvsrepos/ a questo punto tutti gli utenti elencati nel gruppo cvs possono iniziare un nuovo progetto nel nostro repository. Per permettere l’accesso al repository via rete ad utenti privi di un account locale è necessario configurare il password-authenticating server, il servizio si rende indispensabile nel caso si desideri permettere gli accessi anonimi.

Password-Authenticating server

Per prima cosa bisogna accertarsi che nel file /etc/services sia presente un riga come questa:

cvspserver 2401/tcp

che ha il compito di associare il password-authenticating server di CVS alla porta 2401. A questo punto bisogna informare l’Unix Internet Daemon (inetd) su come gestire una richiesta di connessione per il servizio cvspserver, modifichiamo quindi il file /etc/inetd.conf aggiungendo la seguente riga:

cvspserver stream tcp nowait root /usr/local/bin/cvs \
cvs --allow-root=/usr/local/cvsrepos pserver

e riavviamo il demone inetd. Adesso è il turno degli utenti, creiamo il file /usr/local/cvsrepos/CVSROOT/passwd ed inseriamo gli utenti desiderati come nell’esempio:

slackcvs:$1$WuA/mI/0$7XO16pEouKtVlwPylKShr0:slack
anonymous:$1$.Gs0DG/0$KeNxi291fp264R1SHOcT5/

il formato del file è molto semplice e prevede il seguente schema:

<NOME_UTENTE>:<PASSWORD_CRITTATA6>:[UTENTE_DEL_SISTEMA]

dove UTENTE_DEL_SISTEMA è opzionale ed è un login valido sul server CVS, dobbiamo fare attenzione che in /etc/passwd sia presente un utente anonymous:

anonymous:x:1006:100:Anonymous CVS User,,,:/usr/local/cvsrepos/:/bin/false

L’ultimo passo consiste nel creare i file readers e writers nella directory /usr/local/cvsrepos/CVSROOT/ nei quali inserire la lista degli utenti a cui concedere il diritto di sola lettura o di lettura-scrittura. Ovviamente il file readers conterrà almeno l’utente anomimo:

root# cat readers
anonymous

mentre writers conterrà l’altro utente che abbiamo impostato in /usr/local/cvsrepos/CVSROOT/passwd:

root# cat writers
slackcvs

si noti come sia indispensabile una linea vuota al termine di questi file. La configurazione del server CVS è conclusa, ora possiamo iniziare lo sviluppo.

Uso

Iniziare un nuovo progetto

Arjuna Del Toso

Strumenti personali
Namespace

Varianti