[Linux-Biella] Differenze cvs e svn

[Mattia Rossi]

On Mon, 01 Oct 2007 19:49:39 +0200
"Daniele (Mastro)" <daniele.bilug a gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mattia Rossi ha scritto:
> > E' anche vero che al primo merge di una certa
> > consistenza svn/cvs ti fanno bestemmiare come uno scaricatore di porto
> > in giornata di grazia, mentre gli altri, una volta presa confidenza,
> > gestiscono la cosa con molta piu' tranquillita' ...
> 
> qual'è il motivo pratico di tali bestemmie?
> non avendo mai usato nessuno non riesco a immaginarlo
> 

CVS non sa cosa sia una transazione, questo vuol dire che, sia per un commit normale, che per un'operazione di merge, qualche file puo' essere modificato, qualche altro no, il che vuol dire che se non fai piu' che attenzione puoi finire con il tuo bel repository in uno stato di confusione totale.
svn e' piu' moderno, in un singolo commit o tutti i file vanno o tutti rimangono com'erano, svn ha una migliore gestione dei branches rispetto a cvs (soprattutto, usando un database come repository, non duplica file/directory, ma memorizza solo le differenze). Svn non e' in grado di mantenere una storia di branch e merge. Questo vuol dire che, se per esempio hai un progetto che ha multiple releases (branches) che hanno bisogno di essere sviluppate indipendentemente, e mantenute con una certa parte di codice in comune o peggio, se devi applicare lo stesso bug fix a differenti release, devi tenere conto esternamente di quale sia stato l'albero da cui hai ricavato le varie versioni, in maniera di sapere a che livello applicare il fix.
Ad esempio (e lo mantengo semplice, dato che oltre al numero di versione bisognerebbe tener conto del numero di revisione dei singoli commit):
Release 1
Release 1.1 1.2
Release 1.1.1 1.1.2 1.2.1
 
1.1.1 1.1.2 sono mantenute, divergono, in evoluzione, 1.2.1 ha solo manutenzione e bug fixing

Avrai due branch per lo sviluppo, tre branch per la manutenzione
1.1.1b 1.1.2b
1.1.1m 1.1.2m 1.2.1m

Scopri un bug in 1.2.1m, che deve essere messo a posto anche in 1.1.m e non in 1.1.2m perche' e' in un ezzo di codice non piu' presente, se la correzione e' piccola, puoi applicarla singolarmente, due volte, nei due branch diversi, se la correzione e' complessa, non lo puoi / non hai il tempo di farlo, devi andare a recuperare il pezzo di codice in comune facendo un branch da 1 e poi facendo due merge separati (tre, contando che c'e' anche la versione di sviluppo) con le varie branch.
In tutto questo, da quale branch partire e su quale branch fare il merge te lo devi essere scritto su un foglio di carta o in un file esterno a svn.
Con git questo processo e' molto pù semplice perchè le branch multiple ed i merge multipli sono molto più semplici da gestire, e l'algoritmo per fae i merge sbarella molto meno.

Come dicevo nel mio post originario, se il creatore di questo thread semi-infinito deve solo mettere tre script php in un sistema di versioning, qualsiasi strumento va bene, e di sicuro cvs/svn avranno dei client più user friendly.
Se invece il gioco comincia a farsi duro, il fatto di scegliere un tool o l'altro puo' portare a perdere/risparmiere un sacco di tempo e di sonno.
Il risultato dell'usare CVS in un progetto teoricamente complesso come quello descritoo sopra e' il non avere release separate, ma avere un unico minestrone dove non si e' mai in grado di tornare ad una release precedente...

Mattia



---MR.---