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

  • From: Marco Amadori <marco.amadori@xxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Fri, 23 Mar 2012 16:18:08 +0100

Il 23 marzo 2012 14:46, Stefano Cavallari <spiky.kiwi@xxxxxxxxx> ha scritto:
> 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.

Ti ringrazio per l'analisi che hai effettuato, per piacere della
discussione commenterò alcune key features che elenchi, premettendo
che sembra esserci una differenza filosofica profonda tra l'approccio
allo sviluppo che uso io e il tuo, senza per questo dire che il mio è
migliore.

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

Questo è vero ma non devi limitarmi, dammi potere, sono maggiorenne e
sò quando usarlo.

Io riscrivo la storia spesso, per esempio per fornire le mie patch in
testa tramite rebase (feature non dagli inizi presente in hg) e per
riorganizzare i commit dopo fasi di sviluppo molto caotiche.

E dopo la sessione di editing fuoriosa con commits parziali,
riorganizzarsi l'history inmaniera più logica per sé e gli altri.

Fondamentale nel mio workflow.

> Poi non mi piace che sia "normale" ignorare file sotto controllo di
> revisione.

Questo non mi è chiaro, le cose che metti in .gitignore puoi comunque
tracciarle.

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

Questo lo pensavo anch'io all'inizio, ora invece apprezzo e uso
tantissimo l'index e i tool per gestirlo.

Il risultato è che i miei commit e la mia history sono infinitamente
più puliti, condizione necessaria per scoprire regression e per
interagire con altri sviluppatori.

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

Immagino che tu possa avere ragione, per gli usi occasionali git
format-patch o la mia installazione di gitolite coprono le mie
esigenze alla perfezione, ma anche un link simbolico su /var/www non è
la fine del mondo.

Diciamo che per ora non me l'hai venduto, ma tengo le porte aperte ;-)

-- 
ESC:wq
--
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts: