[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi indicò:

> - Everyday GIT with 20 Commands Or So
>   http://www.kernel.org/pub/software/scm/git/docs/everyday.html

Non voglio sembrare quello che si lamenta e basta senza motivo, quindi 
proverò a darti un'idea del perché trovo GIT più complicato di 
Mercurial. Ovviamente vorrebbe essere una critica costruttiva, cosicché 
mi sia più semplice lavorare con i progetti che usano GIT.

> git-init(1) or git-clone(1) to create a new repository.

Ok, qui è uguale.

> git-fsck(1) to check the repository for errors.

«hg verify» ma la sostanza è identica.

> git-prune(1) to remove unused objects in the repository.
> git-repack(1) to pack loose objects for efficiency.
> git-gc(1) to do common housekeeping tasks such as repack and prune.

Ecco, qui mi perdo.

Perché mi avanzano oggetti inutilizzati? Come sono entrati nel repo? Per 
colpa di chi? Perché non sono stati eliminati subito?

Quando devo impacchettare? Spesso? Raramente? Quali sono i tradeoff di 
impacchettare?

git-gc chiama gli altri due aggiungendoci un po' di logica, quindi 
-prune e -repack per me non esistono. Posso però chiamarlo dopo ogni 
commit? Perché non è automatico?

> git-pull(1) and git-fetch(1) from "origin" to keep up-to-date with the upstream.

git-pull è git-fetch + git-merge.

git-fetch modifica la working directory?

git-merge fonde due rami, il mio e quello remoto. Ma se io ho solo 
cambiamenti nella working dir di cui non ho fatto commit, me 
                                                  li fonde con la cima 
del ramo corrente?

> git-push(1) to shared repository, if you adopt CVS style shared repository workflow.

Qui la descrizione è fuorviante. Cosa centra CVS? Io faccio push sui 
miei repo pubblici su techn.ocracy.org, che non sono "shared" con nessuno...

Per il resto sono talmente simili che le motivazioni tecniche si 
esauriscono e diventa solo una questione di gusti...

Ad esempio il formato del repository di GIT è più semplice ed elegante, 
ma solo se non si considerano i pack. Con questi allora è il formato di 
Mercurial a essere quello più omogeneo ed elegante, non necessitando di 
alcuna manutenzione.

Mercurial ha una implementazione sufficientemente pulita in Python con 
alcuni pezzi critici in C. GIT è in parte C, in parte bash e in parte Perl.

In git vorrei una netta distinzione tra il plumbing e le porcelain, 
cosicché io possa allegramente ignorare del tutto i primi. In Mercurial 
il problema non si pone essendo plumbing i moduli Python interni non 
esposti dalla ria di comando.


Poi c'è una cosa che mi è ancora molto nebulosa.
Come sono organizzati i branch di GIT?
Come sono implementati?
Come tiene conto della provenienza?
Se lo stesso cset viene scaricato da due branch differenti, a quale dei 
due appartiene?
Un branch può avere più teste?

Grazie. ;P

-- 
Buongiorno.
Complimenti per l'ottima scelta.