[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Mattia Rossi evidenziò:

> ... e' un po' come chiedere di essere consigliato su quale
> distribuzione, o quale database usare ... la risposta e'
> invariabilmente:
> Che cosa ci devi fare ?

Escludendo requisiti di compatibilità con software esterni, considererei 
le soluzioni centralizzate tecnicamente obsolete.

Quantomeno per il fatto che quelle distribuite possono essere impiegate 
anche in modo centralizzato senza troppo sforzo.

> Se hai bisogno di svn/cvs/git per razionalizzare (e magari avere un
> backup) la tua libreria di codice, o quella di un piccolo team, allora
> va dove ti porta il cuore (nel senso, prova tutt'e' tre, vedi quale
> client ti piace di piu', usalo per un po', e poi torniamo a parlarne)

Quello di provare con le proprie mani è sempre il consiglio migliore. :)

> Se hai bisogno di un sistema di versioning control/branch
> management/release management/ per gestire decine o piu' di progetti
> con decine o piu' di sviluppatori e decine o piu' di release,
> customizzazioni e menate varie, la risposta puo' variare molto a
> seconda della tipologia dei progetti, per certe cose (poche) e' meglio
> svn (curva di apprendimento, diffusione, tools, similarita' con cvs) e
> per certe cose e' meglio git (facilita' di branching e merging,
> principalmente).

Personalmente credo che la curva di apprendimento meno ripida sia quella 
di Bazaar e Mercurial.

CVS assolutamente no. Spesso ci si riduce a pacioccare a mano i file RCS 
con i conseguenti danni.

SVN richiede maggiore sforzo a causa della configurazione del repository 
centrale.

GIT sta migliorando ma la curva di apprendimento resta abbastanza ripida.

Darcs ha una curva tutto sommato bassa, ma ha seri problemi a livello di 
implementazione. Sarebbe bello se riuscissero a sistemarlo.

> Se hai bisogno di gestire centinaia di progetti con centinaia/migliaia
> di programmatori, allora forse hai bisogno di qualcosa tipo perforce
> o , meglio, sourceforge (vendono una versione enterprise del loro
> ambiente di gestione progetti), ma qui si parla di decine/centinaia di
> migliaia di euro, per progetti che ne hanno veramente bisogno.

Non ho mai usato Perforce, anche per il fatto di essere non-free.

SourceForge usa SVN, ma sul wiki di Mercurial ci sono le istruzioni per 
usare l'hosting web fornito per ospitare il relativo CGI.

Ciò nondimeno credo che, riguardo lo scalare del numero di sviluppatori, 
l'esempio del kernel sia la dimostrazione che la via migliore sia un DVCS.

Così come xorg, Mozilla, OpenSolaris, Java...

> Il discorso "Cvs e' una merda perche' lo dice Linus"  e' una cazzata
> allucinante, non tutti i progetti hanno la complessita' del kernel
> linux e non tutti i programmatori/project manager hanno la testa di
> Linus, IMHO.

In realtà funziona così: "CVS/SVN sono una merda perché quando Linus lo 
dice lo motiva anche".

Consiglio caldamente il video indicato da Paolo.

> Git/mercurial, soprattutto se uno
> non ha gia' le sinapsi predisposte per aver usato precedentemente cvs
> o, peggio,rcs hanno un potenziale di evoluzione molto maggiore, ma
> secondo me per progetti medio/piccoli cvs/svn sono di piu' facile
> apprendimento immediato. 

Le righe di comando di Mercurial e di Bazaar sono molto simili a quella 
di SVN, quindi nessun trauma.

L'unico compromesso pergli utenti di SVN/CVS è di barattare il concetto 
di locking con quello di merge.

In realtà dovrebbero già sapere come si fa un merge, solo che in un DVCS 
avviene molto più frequentemente.

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

Esatto!

E se non si è soli i merge vanno fatti comunque, anche se sono solo tra 
la propria copia locale e ciò che altri hanno committato.

Il concetto alla base di tutti i DVCS è di rendere i merge quanto più 
facili possibile. Idee diverse riguardo al modo di arrivare questo scopo 
hanno dato origine alla moltitudine di soluzioni differenti.

-- 
Buongiorno.
Complimenti per l'ottima scelta.