[Linux-Biella] svn vs git

[Daniele Segato]

Il giorno mar, 28/09/2010 alle 09.07 +0200, Marco Vallini ha scritto:
> Buondì,
> di solito uso svn + trac, ma ho sentito tanto parlare di git in questa 
> ml. A questo punto pongo la domanda ai più esperti:
> git è meglio di svn? Se si per quali aspetti?
> Non mandatemi link vari di paragone, vorrei che mi rispondesse qualcuno 
> che ha esperienza diretta.

prima di tutto

SVN è centralizzato

Git è distribuito

ma questo te lo hanno già detto e comunque non è l'unica differenza

i sistemi centralizzati sono "la vecchia generazione", quelli
distribuiti sono stati creati per ovviare alle problematiche dei primi

è un po' come confrontare un'abaco con una calcolatrice secondo me.

se sai usare l'abaco e cerchi di usare la calcolatrice ti sembrerà
complessa o "strana", ma è indubbio che sia più avanzata la seconda.

in un sistema centralizzato c'è un solo server che si tiene la storia
dei commit.
Ogni utente per lavorare deve interfacciarsi con il server (ovvero avere
una connessione)

gli utenti hanno sempre un'unica versione locale alla volta

significa che non puoi lavorare su due cose contemporaneamente o saltare
da una all'altra
non puoi fare un commit finché tutto non è perfettamente funzionante e
testato



in un sistema distribuito invece tutti gli utenti hanno l'intera copia
del repository e possono lavorarci offline facendo commit, branch,
merge, ecc... ecc...

esempio pratico
stai sviluppando "fantasmagorifa-e-grandissima-feature" quando in
produzione accade "devastante-e-urgentissimo-bug" che, guarda caso,
interessa alcuni dei file che stai modificando per la feature

su subversion sei sostanzialmente nei cazzi
o ti fai un checkout separato da un'altra parte, riconfiguri tutto e
lavori lì oppure salvi tutto il lavoro, revert, risolvi il bug poi
ripristini

su git (o altro sistema distribuito) fai un bel commit temporaneo (si
temporaneo) crei un'altro branch risolvi il bug, torni al branch della
feature


sei in pullman e vuoi vedere chi ha scritto quella riga di codice lì e
perchè? hai tutta la storia dei commit, puoi farlo

se invece hai subversion, ahi ahi ahi ahi...


in un sistema distribuito non è obbligatorio avere un solo server
centrale, puoi averne 2, 3, 4, quelli che vuoi

puoi anche sincronizzarti con il tuo collega se stai lavorando ad una
feature con lui

in genere c'è sempre un repository "eletto" a principale, ma non è
detto, dipende da come si vuol strutturare il progetto.

immagina che un progetto git subisca un fork, tu puoi seguirli entrambi
in un unico repository, sincronizzarti da uno all'altro o portare commit
da uno all'altro secondo l'occorrenza


ogni commit, su git, ha un hash che dipende dal commit stesso.
Quindi è univoco, ovunque venga portato.
Il commit con hash ABCD ha lo stesso hash su qualunque repository



questo per grattare la crosta dei vantaggi di un sistema distribuito


ma se confronti subversion con git ci sono altre differenze

subversion memorizza la storia dei commit in un albero

git usa un grafo

cosa significa?
che i merge sono reali e funzionano

su subversion si creano pochissimi branch perché fare i merge è un
delirio
su git invece è comodo e ci si abitua a crearne tanti


in effetti cambia il concetto di branch: un branch rappresenta una
funzionalità: quando ne ho bisogno mi basta mergiarla su un altro branch
se scopro un bug non lo sistemo sul "trunk" come nuovo commit ma
identifico il commit che ha introdotto il problema e lo risolvo su un
branch che parte da quel commit
quindi mergio la fix ovunque ne ho bisogno

quel "piccolo" branch rappresenta a tutti gli effetti la fix


e fin qui git e mercurial si equivalgono direi.

mercurial non lo conosco molto, ti posso dire il poco che so

mercurial pare funzionare più fluido su windows rispetto a git
git infatti è molto legato ai tool unix (script shell, perl, e
filesystem unix per esempio) su windows per usarlo si deve installare
con cygwin o simili (vedi msysgit)

git anni fa era molto complesso e si è fatto la fama di essere
difficile.
da allora però lo sviluppo si è concentrato molto su quest'aspetto e ora
è diventato davvero semplice da usare

nonostante ciò credo che rispetto a mercurial metta a disposizione una
maggior quantità di funzionalità
inoltre se conosci un po' di shell scripting è immediato integrarlo a
tuo piacimento con script di verifica, manipolazione, controllo che
velocizzano il lavoro


i contro che vedo nel passaggio da svn a git
 - imparare un nuovo sistema
 - gestione di grossi/tanti file binari (git non è molto portato a far
questo)
 - eventuali migrazioni di script aziendali per subversion

chi si è schierato contro git per ora ha sempre parlato senza conoscere
realmente il sistema per com'è ADESSO. io qui mi sono limitato ad
evidenziarti ciò che ritengo buono di git e i difetti che conosco, non
mi esprimo su mercurial perché non lo conosco

comunque non ti puoi rendere conto dei vantaggi finché non cominci ad
usarlo un po'.