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

  • From: Stefano Cavallari <spiky.kiwi@xxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Fri, 23 Mar 2012 18:07:08 +0100

On 03/23/2012 04:18 PM, Marco Amadori wrote:
> Il 23 marzo 2012 14:46, Stefano Cavallari <spiky.kiwi@xxxxxxxxx> ha scritto:
> 
> 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.
Non lo mettevo assolutamente in discussione; ma il default conta molto
nel far capire cosa è assolutamente normale e cosa va fatto con un po'
di cautela e non è immediatissimo.
Il disabilitarlo di default è un modo, un altro è dargli posizioni
diverse nella documentazione e visibilità; su questo si può discutere.
Vedo che versioni recenti di git mostrano solo comandi semplici nel
--help; peccato che nell'help dei comandi stessi poi non ci sia la
stessa scelta, almeno nel separarli.

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

Anche io. Ma prova a far fare un rebase con conflitti ad un novizio,
secondo me si incasina e finisce che perde tutto o committa grafi
impensabili.

> 
> 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.
> 
MMh non ho capito, espandi con un workflow tipico.
>> 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.
Anche qua, fammi un esempio :)
> 
> 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.

Pienamente d'accordo che cambiare la history locale è molto utile,
infatti uso molto rebase e mq.

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

> Diciamo che per ora non me l'hai venduto, ma tengo le porte aperte ;-)
> 
Anche di qua non si chiudono mai :)

Other related posts: