[Python] Git, Mercurial o subversion

[Enrico Franchi]

Andrea Francia wrote:

> Quando ho scritto che è meno complicato intendevo che:
>   - un versioning centralizzato è più facile da spiegare a persone che
> non ne sanno poco o niente di VCS

E di questo non ne sono esattamente convinto. In particolare, la mia 
impressione e' che, anche ammettendo che la distribuzione aumenti la 
complessita' (dal mio punto di vista invece la riduce, perche' si passa 
da un modello asimmetrico ad uno simmetrico), tale aumento sia 
irrilevante rispetto alla complessita' di spiegare i fondamenti di SCM.

>   - che subversion ha meno comandi/concetti degli altri due.

Non so... non li ho contati! ;)
Certo, git ha un dozilione di comandi; ma a parte questo le operazioni 
elementari che effettivamente si fanno sono grosso modo le stesse. E se 
uno e' veramente da solo non ha nemmeno il problema della 
sincronizzazione remota.

Che non credo sia un problema per chi ha usato il computer da un 
pochetto: concettualmente il fatto che ci mandiamo avanti e indietro 
dati in rete e compagnia e' qualcosa che abbiamo acquisito da tempo. 
Insomma, non credo che il difficile siano pull/push.

> Avevo in mente persone che poi avrebbero dovuto usare il VCS per
> checkout e commit, persone che neanche si sognerebbero che si possono da
> sole mettere in piedi un server.
>
> Per il resto sono d'accordo con te, che per creare un repository con hg
> e git non ci vuole solo un comando (init), che ci vuole poco a spingere
> il repository sul server, e che i merge e i branch sono un dolore con
> Subversion.

Eh, ma purtroppo ci passi. Il merge prima o poi ti capita. Se lavori con 
un'altra persona e' una certezza; se lavori da solo ma su piu' 
postazioni pure.

E il branch e' uno strumento troppo importante per non volerlo imparare 
prima o poi, con un certo bias verso il "prima" perche' permette di fare 
cose importanti. Poi sono d'accordo che una serie di persone cercano di 
evitarlo, ma questo solo perche' in molti sistemi e' un'operazione 
inutilmente complessa da fare e da riunire.


> Su Subversion non è proprio vero che devi 'per forza' configurarti un
> server, come CVS puoi fare un repository in locale ma è vero proprio una
> soluzione da sconsigliare.

Vero. Ma appunto... non la consiglierei.

> Secondo me non è proprio esatto dire che
> Subversion copia tutti i file quando fai un branch perché nel repository
> ne resta una copia sola però riferita due volte, quindi lo spazio non è
> sprecato.

E' vero. Remotamente ne resta solo una copia.

> È però che il filesystem finale appare come se contenesse una
> copia di tutti i file e quindi (a parte lo spazio) crea uno spreco e un
> casino di namespace del filesystem.

Esatto. Poi voglio dire... lo spazio; i nostri favoriti si tirano dietro 
tutto il repo, quindi li vince comunque svn. Sempre se la memoria non mi 
inganna. Credo che siano anni che non lo uso.


> A scanso di equivoci la mia preferenza va a Git. A me piace perché anche
> se è complicato è anche super potente. La menata dell'add secondo me ha
> il suo perché, mi evita di committare per sbaglio cose che non dovevo.

Sono d'accordo sul fatto che ha un suo senso. Non ho ancora deciso se mi 
piace o meno. Esattamente come l'edit di Perforce ha un suo senso... ma 
dopo un po' veramente non ne potevo piu'.

L'add dura perche' mi e' capitato piu' spesso di quanto avrei voluto di 
fare casino con -a e -m in combinazione. Ho trovato che -a aprendo vim e 
mettendo li il commit e' abbastanza safe, nel senso che mentre scrivo 
vedo "naturalmente" cosa sta includendo. Viceversa se uso -m mi e' 
capitato che scappa dentro roba che non avrebbe dovuto.

-- 
.
..: -enrico-