[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi confrontò:

>>>     * You can do selected files commit with a fine granularity,
>>> telling git what you want to do little by little (git add file to add
>>> the full content of the file to the index, git add -i or git-gui to
>>> add the content hunk-by-hunk, or even use the hunk splitting feature
>>> of git add -i).
>> Questo lo si puo fare in altri modi senza index:
>> * elencando i file al momento del commit
>> * usando darcs/hg record e selezionando interattivamente file e hunk
> 
> E questo lo si puo' fare anche con git.

Sì, appunto, non mi sembra necessario l'index esplicito per questo.

L'index in sé per me va benissimo, è solo che non capisco perché mai non 
sia del tutto nascosto.

>>>     * This selected files commit can help you to keep an uncommited
>>> modification in your tree for a reasonably long time. For example, you
>>> can increment the version number in the Makefile some time before a
>>> release, and use this as a reminder.
>> Ok, questo con gli altri non si può fare, ma non mi sembra che il gioco
>> valga la candela.
> 
> Tutto e' sempre una questione di punti di vista :-)

Ovvio, ma qui si introduce un concetto nuovo e, a meno che di 
sostanziosi vantaggi, questo è oggettivamente un carico ulteriore per 
l'utente.

Il mio tentativo è di capire quali siano i sostanziosi vantaggi. :)

>> Usare cambiamenti non committati credo sia un pessimo modo di segnarsi
>> le cose da fare...
>>
>> Oltretutto credo un VCS dovrebbe evitare di invogliare l'esistenza di
>> cambiamenti che rimangono non committati per lungo tempo, in quanto sono
>> quelli che vengono persi in caso di rottura del disco, «rm -Rf /», eccetera!
> 
> Stai un po' estremizzando in commento di Linus, credo che non sia un
> problema perdere la modifica alla versione del Makefile per lui :-)

Sono d'accordo, ho estremizzato un po'. :)

Però mi sembra anche eccessivo elencare questo uso tra i vantaggi di 
avere un index esplicito.

> In generale, trovo comodo fare delle modifiche, aggiungerle/toglierle
> all'index e fare:
> $ git diff --index
> per vedere quello che verra' incluso nel prossimo commit.

Secondo me la stessa cosa si può fare con "amend" in modo più semplice.

Altrimenti elenchi i file la prima volta che fai diff e poi usi la 
history della shell... ;)

> Ma come ho detto in precedenza, se non ti piace ti crei un alias a
> commit -a e ti dimentichi della staging area.

Ma io voglio poter usare felicemente GIT senza dovermi sbattere!

Se con Mercurial ce l'ho fatta, voglio almeno avere ottimi motivi per 
non poterlo fare con GIT.

>> GIT rende uguali le cose semplici e complicate, ma non sono sicuro sia
>> una cosa buona. :)
> 
> ...e veloci...Cof cof...
> http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html

Senza dubbio.

A fare diff Mercurial sarà sempre più lento di GIT per come è fatto il 
formato interno (spesso deve ricostruire in parte i file).

È un tradeoff diverso (annotate più veloce, non servono pack, realmente 
append-only).

Mercurial paga anche la lentezza a partire e a importare moduli 
dell'interprete Python.

C'è anche da dire che l'ultimo commento della pagina sembra evidenziare 
un problema nelle ultime due righe del benchmark, visto che git-diff usa 
la directory corrente mentre gli altri percorrono l'intero repo.

Negli ultimi giorni è stato velocizzato (in C) il walking del repo in 
Mercurial, sarebbe interessante vedere se ci sono miglioramenti non solo 
in "hg status".

Comunque, la vera conclusione è che Bazaar sia LENTO! ;)

Ultimamente pare l'abbiano migliorato, comunque.


>>> Indeed, the real reason according to Linus is more philosophical: git
>>> is a content tracker, and a file name has no meaning unless associated
>>> to its content. Therefore, the only sane behavior for git add filename
>>> is to add the content of the file as well as its name to the index.
>> Ok, ma io non uso un VCS per motivi filosofici, come non uso il software
>> libero per motivi filosofici.
>>
>> Per di più detto da un pragmatico come Linus lo interpreto solo come una
>> battuta. ;)
> 
> Ama "stressare" il fatto che git fa il tracking dei contenuti e non
> dei file (nomi di)

Lo so. Ma io voglio un VCS, non un content-addressable FS!

GIT mi va bene come backend, ma fintanto che non vedo un vero VCS sopra 
continuo a ritenerlo complicato...

-- 
Buongiorno.
Complimenti per l'ottima scelta.