[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi delineò:

>>>> "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
>> Sì.
> 
> Quindi per fare il tracking di un progetto tu fai
> $ hg pull -u
> 
> Curioso.

Esatto. Se invece ci sto lavorando faccio solo "hg pull" e quando ho 
voglia ne faccio il merge.

>>>> 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. :)
> 
> Questo avveniva anche con cogito (progetto ora dismesso) ma...
> 
> Linus Torvalds once said, "If you deny the Index, you really deny git
> itself." (February 4, 2006, Git List Archives)
> 
> E ora che conosco meglio git devo dire che Linus aveva ragione.

Continuo a non capire quali siano i superpoteri derivanti da avere 
l'index esplicito... :(

E mi sono letto tutto "Embrace The Git Index"!

>> $ hg commit -m "ho modificato A e B" fileA fileB
>> $ hg commit -m "ho modificato C" fileC
>>
>> Nell'ultimo puoi omettere "fileC", essendo l'unico file ad avere
>> modifiche non commitate.
>>
>> Stessa cosa dicasi per SVN/Darcs/Bazaar. Persino CVS.
> 
> OK.
> 
> Ma quello che puoi fare con git è:
> modifico A
> modifico B
> git add A B
> modifico ancora A
> Decido se aggiungere questa ulteriore modifica di A all'index
> commit
> 
> E in un qualunque momento posso fare:
> git diff --index per vedere quello che sara' inserito nel prossimo commit.

In tal caso è un semplice commit a due stadi: faccio commit nell'index e 
poi faccio il commit vero e proprio.

Darcs risolve elegantemente il problema con "darcs amend-record", il 
quale incorpora le attuali modifiche alla working directory nell'ultimo 
commit fatto (ovviamente a patto che questo non sia stato già distribuito).

# modifico A
# modifico B
$ darcs record -a A B
# modifico ancora A
$ darcs diff
# Decido se aggiungere questa ulteriore modifica di A al commit
$ darcs amend-record -a A

In questo modo non si introducono dettagli implementativi come l'index e 
non serve usare alcuna opzione di "darcs diff" in quanto quello 
intermedio è un commit vero.

Vedrei bene un'estensione analoga per Mercurial ("hg amend"), visto che 
io uso MQ per fare la stessa cosa ma è un po' macchinoso:

# modifico A
# modifico B
$ hg commit A B
# modifico ancora A
$ hg diff
# Decido se aggiungere questa ulteriore modifica di A al commit
$ hg qimport -r .
$ hg qrefresh A
$ hg qdelete -r .

L'idea è che gli ultimi 3 comandi vadano sostituiti con un singolo "hg 
amend".

Negli esempi ho sempre elencato esplicitamente i file A e B ma non è 
necessario se questi sono gli unici a essere stati modificati.

> Se ci pensi bene, l'uso dell'index ti permette moltissime modalità
> lavorative differenti.

Boh, piuttosto di un commit a due stadi con index esplicito a me sembra 
molto più semplice avere un comando "amend".

> Per progetti piu' semplici si puo' comunque creare un alias e avere lo
> stesso comportamento di HG (commit -a di default).

Non credo sia questione di complessità del progetto.

Io mi ritrovo spesso a usarlo anche con repository molto piccoli.

Per lo scenario che hai descritto la soluzione di Darcs mi pare la migliore.

Rispetto a GIT consente persino di modificare il messaggio di commit per 
correggere gli errori ortografici che immancabilmente faccio! ;)

> Oppure usi git-gui (mai piu' senza).

No, vivo in un terminale con shell e vim, una GUI mi darebbe solo 
fastidio. Senza contare il fatto che spesso la userei via SSH... :)

-- 
Buongiorno.
Complimenti per l'ottima scelta.