[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi anticipò:

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

Speriamo. :)

>> 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 :-)

Speriamo tanto. :D

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

Ti spiego come funziona in Mercurial così forse i miei dubbi sono più 
chiari. :)

hg clone http://selenic.com/hg/

cd hg

# passa del tempo, il repository remoto viene aggiornato

hg pull   # scarica e aggiunge i nuovi cset al DAG della storia senza
           # toccare la working directory

hg update # aggiorna la working directory portandola alla punta del DAG
           # della storia

"hg pull" e "hg update" possono venire fusi con "hg pull -u" se si vuole.

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

hg clone http://selenic.com/hg/

cd hg

# passa del tempo, il repository remoto viene aggiornato
# nel frattempo aggiungo la feature "world domination" ma non ne faccio
# ancora commit

hg pull   # scarica e aggiunge i nuovi cset al DAG della storia senza
           # toccare la working directory

hg update # aggiorna la working directory portandola alla punta del DAG
           # della storia, fondendo i miei cambiamenti con quelli remoti

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

Se lo è la documentazione, figurati il sottoscritto. %-)

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

Meno male.

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

Letto, ma non capisco a cosa serva.

O meglio, capisco la sua utilità dal punto di vista interno, ma non 
capisco a cosa serva esporlo all'utente.

Mi sembra solo una specie di commit a due stadi senza particolari benefici.

Fortunatamente in Mercurial il dirstate (il quasi corrispettivo 
dell'index) è completamente nascosto all'utente. :)

>> Un branch può avere più teste?
> 
> Si.

Come? Da quel che ho capito un branch è identificato dal suo cset più 
recente.

I branch di Mercurial sono bestie differenti.

Ce ne sono di due tipi, come in GIT: quelli in stile Bazaar, ovvero i 
cloni di un repo, e quelli interni.

Quelli interni sono intesi per casi d'uso differenti da quelli in stile 
Bazaar in quanto, a differenza di questi, il nome del branch a cui un 
cset appartiene viene memorizzato all'interno della storia stessa.

Sono utili quando si vogliono mantenere linee di sviluppo differenti 
all'interno dello stesso progetto.

O almeno quella è la motivazione, solitamente vengono utilizzati molto 
raramente.

Essendo i branch interni di GIT non memorizzati nella storia non hanno 
una grande differenza rispetto a quelli esterni.

Anzi, per questo io preferisco questi ultimi visto che mi sembrano più 
"espliciti" e non richiedono altre conoscenze oltre al basilare "clone".

Perché dovrei usare quelli interni in GIT?

-- 
Buongiorno.
Complimenti per l'ottima scelta.