[Linuxtrent] Re: Subversion, che mal di testa!

  • From: Stefano Cavallari <spiky.kiwi@xxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Fri, 23 Mar 2012 14:46:40 +0100

On 03/23/2012 12:40 PM, Marco Amadori wrote:

> Come frontend brz non era malaccio, ma l'efficienza e alcuni problemi
> iniziali di gioventù me lo hanno fatto abbandonare per git nel lontano
> 2007. Proverò nuovamente hg, ma parto con degli anni alle spalle di
> git, difficile che senza killer feature particolari mi possa far
> abbandonare git che ormai padroneggio e che ha pure gran 'momentum'
> nelle community.

<scherzo>ovviamente risparmi un keypress!</scherzo>
Effettivamente vere killer features non ce ne sono.
Però qualche comportamento che fa la differenza per me c'è, gli elenco
qua, non per fare polemica ma per una discussione su vantaggi e
svantaggi dei due sistemi. Si parla di interfaccia, perché a livello di
dati sono praticamente equivalenti a meno dei tag e di qualche altro
dettaglio [0].
Ovviamente mi interessano pareri su hg che a me sembra perfetto ma di
sicuro qualche problema ce l'ha anche lui.

In git ci sono comandi che cambiano la history. Anche in hg, ma sono
disabilitati per default. Mi sembra una scelta migliore, la history va
cambiata solo in caso di effettiva necessità, si possono creare problemi
noiosi ad altri committers.
Più in genere il set di comandi iniziale è il minimo necessario, poi con
la crescita dell'esperienza si abilitano feature comode ma non
fondamentali (e spesso fuorvianti).
Non sono difficili da abilitare, assolutamente; non sono certo il genere
di utente a cui piacciono le interfacce limitate a tutti i costi (alla
gnome :P), ma un minimo di pulizia ci vuole, a patto di non rendere
impossibili le cose avanzate ma solo di metterle in uno spazio adeguato.

Poi non mi piace che sia "normale" ignorare file sotto controllo di
revisione.
In hg non si permette questo comportamento che è abbastanza rischioso,
può succedere di dimenticare cambiamenti sparsi nei sorgenti, e inoltre
si mettono i file di configurazione sotto controllo di revisione e non
un loro template. Rende particolarmente noioso aggiornare il file
ignorato. Mi è capitato di trovare progetti che usano git con il file di
configurazione di default totalmente obsoleto. Qualcuno dirà che è colpa
dell'utente, ma perché promuovere inutilmente una cattiva abitudine?

Inoltre i file da committare vanno aggiunti esplicitamente, preferisco
il comportamento di default di hg di committare tutto se non
diversamente indicato. Spesso uso hg record per selezionare cosa
committare, ma a livello di chunk non a livello di file. La granularità
a livello di file di git add, e più in genere la gestione manuale della
gestione dell'index le trovo assolutamente inutili.

Su hg c'è "hg serve" crea un semplice webserver out of the box da cui si
può pullare e navigare nella history e nei tree. È veramente utile
quando in una lan si scambiano commit senza avere un server
centralizzato, ma anche per navigare in locale il repository. In git non
c'è niente di altrettanto veloce e pulito (e non ditemi di usare github
e simili, non è una soluzione).

Poi beh, il numero di opzioni eccessivo per ogni comando, la
documentazione bruttina, ma queste sono una vecchia storia.

Saluti,
    Stefano

[0] http://mercurial.selenic.com/wiki/GitConcepts

Other related posts: