[Linux-Biella] Differenze cvs e svn

[Paolo Ciarrocchi]

On 10/3/07, Emanuele Aina <em a nerd.ocracy.org> wrote:
> 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?

" Aborting operations or backing out changes will leave useless
dangling objects in the database. These are generally a small fraction
of the continuously growing history of wanted objects, but checking
for dangling objects using git-fsck-objects and reclaiming the space
using git-prune can be slow. Pruning also breaks immutability of the
database. Newer version of git feature a git-gc command which will
combine the pruning and packing."

_Credo_ che nelle prossime versioni di GIT git/gc verra' invocato
automaticamente in alcune circostanze.


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

Onestamente queste dubbi devono nascere solo se hai dei repository _enormi_.
Nella documentazione mi sembra si consigli di fare un repack una volta
alla settimana, per esempio mettendo il comando in crontab.

> 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?

Perche' sta per diventare 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?

Cioe?

> 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?

Credo di si ma non mi e' molto chiaro lo scenario.

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

Anche io lo faccio. La descrizione voleva ricordare l'uso di GIT con
_UN_ repository centralizzato. E' sicuramente confusa.

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

Vero. Anche se come ho scritto in precedenza si sta lavorando per
rendere la "manutenzione" automatica.

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

Quasi tutto ora convertito in C. Al punto da esserci un installer per
windows (nativo, non cygwin).

> 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?

Wow... dovrei scrivere pagine e pagine di risposta (e leggere un po'
di documentazione).

_Credo_ che una differenza tra GIT e Mercurial sia l'uso dell'index  (
o cache), io mi sto leggendo
http://www.jdl.com/papers/Embrace_The_Git_Index.pdf

> Un branch può avere più teste?

Si.

> Grazie. ;P

Prego. Anche se ho risposto a pochi dubbi...

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com