Home
Repository 32bit  Forum
Repository 64bit  Wiki

Modifiche

Breve introduzione a CVS

161 byte aggiunti, 17:47, 9 set 2006
nessun oggetto della modifica
# 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>
{| align=center| [[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
* cliccate il pulsante “Aggiungi” ed inserite il valore desiderato, nel nostro caso '':pserver:slackcvs:secret@192.168.1.1:/usr/local/cvsrepos/'', come mostrato in Figura 2
{| align=center|[[Immagine:cvs2.png]]|}
* quindi “OK” ed ancora “OK”.
Cervisia è in grado di gestire più repository contemporaneamente quindi, se ne abbiamo necessità, possiamo ripetere la procedura precedente il numero di volte desiderato.
{| align=center|[[Immagine:cvs3.png]]|}
Ora che il repository è stato identificato dobbiamo scaricare i file del progetto. Questo può sembrare strano visto che abbiamo gli originali ancora sul nostro disco ma, a ben guardare, quella directory non contiene informazioni riguardanti CVS. Andiamo a fare quindi il nostro primo checkout con il quale verrà creata la sandbox:
* indichiamo il repository, il progetto (“Modulo”), la directory di destinazione e diamo l’“OK”.
{| align=center|[[Immagine:cvs4.png]]|}
Nel luogo indicato per la creazione della sandbox, CVS creerà gli stessi file e directory che abbiamo importato sul server, con l’aggiunta di un’ulteriore directory CVS in tutta la struttura11. CVS utilizza l’omonima directory
il formato di queste informazioni segue il modello /nome file/numero di revisione/data e ora// per i file (che possono tranquillamente avere numero di revisione differente l’uno dall’altro), le directory invece non hanno numeri di revisione o data e vengono indicate con la lettera “D”. La Figura 5 mostra il risultato delle nostre azioni. Nella parte alta della finestra troviamo le cartelle e i file che compongono il progetto hello_world, nella parte bassa abbiamo l’output del comando di checkout. Accanto adogni file, Cervisia mostra il suo stato (attualmente tutti i file sono in stato "Aggiornato" a causa del checkout), il numero di revisione (tutti i file partono dalla revisione 1.112) e il timestamp con l’indicazione della data.
{| align=center|[[Immagine:cvs5.png]]|}
Applichiamo qualche semplice modifica al file ''HelloWorld.java e DirB/Predi.java''. Notiamo come lo stato dei file rimanga "Aggiornato" anche se noi sappiamo che questo non corrisponde a verità. Come mai? La risposta è semplice: dal momento del checkout CVS non ha più comunicato con il server e quindi non può fare nessuna supposizione sul reale
spedire al server la versione aggiornata del progetto. È tempo di fare un commit e, quindi, selezioniamo la directory principale e poi "File &rarr; Fai Commit". Ci verrà presentato un box in cui sono elencati i file che stiamo inviando ed un’apposito campo di testo in cui inserire il commento al commit. Effettuata l’operazione lo stato dei file tornerà ad "Aggiornato" e verrà incrementato di uno il valore della revisione. ''HelloWorld.java e DirB/Predi.java'' adesso saranno in revisione 1.2, tutti gli altri ancora fermi a 1.1. La Figura 6 mostra la situazione dopo un’ulteriore modifica a ''Hello-World.java'' seguita da un update. Un nuovo commit porterà ''Hello-World.java'' alla revisione 1.3 e così via.
{| align=center|[[Immagine:cvs6.png]]|}
=== Aggiungere e rimuovere file o directory ===
Bisogna notare come ciò non significhi aggiungere un tag a tutti i file con uguale numero di revisione, bensì marcare i file con il più alto numero di revisione disponibile nella working copy associandoli allo stesso tag (la Figura 7 mostra questa situazione). Il tag è applicato immediatamente sia nella working copy che nel repository, non c’è quindi la necessità di effettuare un commit poichè i file coinvolti non vengono modificati ma soltatno le informazioni contenute nei logs. Se nella working copy dello sviluppatore sono presenti delle modifiche ai file, rispetto al repository, queste non verranno prese in considerazione da cvs e il tag interesserà il numero di revisione più alto per quel file al momento presente nel repository. Per questo motivo si tende a sincronizzare la sandbox con il repository prima di applicare un tag.
{| align=center|[[Immagine:cvs7.png]]|}
Per ottenere uno snapshot basato sui tag è sufficiente passare il suo nome a CVS come fosse un numero di revisione:
a questo punto è possibile apportare tutte le modifiche necassarie a risolvere il bug ed effettuare il commit che ci permette di tenere traccia del nostro lavoro. Il commit creerà una versione parallela del progetto basata sui sorgenti associati al tag utilizzato (Figura 8). Da questa versione parallela possiamo ricavare una patch da distribuire priva del bug. Nel caso ci rendessimo conto che anche la versione attualmente in sviluppo è soggetta allo stesso bug, CVS ci permette di utilizzare il lavoro fatto sul branch per risolvere la questione. È possibile infatti eseguire un merge dal branch al trunk:
{| align=center|[[Immagine:cvs8.png]]|}
cvs -q update -j Rilascio_2005-02-13-bugfix-branch
789
contributi