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-

_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Rispondere a