[Linux-Biella] Differenze cvs e svn

[Paolo Ciarrocchi]

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

come git fetch direi

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

Se deve essere preceduto da hg pull allora è come git merge

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

Se ho capito bene hg pull -u equivale a git pull

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

E qui inizio io a fare le domande :-)

In git puoi fare.
- Modifico fileA
- Modifico fileB
-Modifico fileC

git commit -a -m "Ho modificato A B e C" oppure
git add fileA fileB (fileA e fileB sono nella "staging area")
git commit -m "ho modificato A e B"
git add fileC
git commit -m "ho modificato C"

Come posso farlo in HG?

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

Scusa ma non ti ho seguito (mattina presto, senza caffe'...)

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