Da SVN a Git ? Ne vale la pena?

Jeff

unread,

May 10, 2013, 10:20:22 AM5/10/13

to

Buondi,

Dove lavoro stiamo ampliando il team con nuovi programmatori e collaboratori.

Attualmente utiliziamo SVN, e benche' siamo un team minuscolo, 2 resident e di tanto in tanto qualche esterno, e' capitato piu' di una volta di avere millanta problemi di merging, fare update su deployment sbagliati con versioni sbagliate (come postai e mi consigliaste di utilizzare svn tag :-) ), problemi con i file binari (non so esattamente se dovuto a svn o qualche altro problema) e praticamente incubi nel creare e riaccorpare branch.

La situazione sara' di avere piu' persone in ufficio ed anche piu' persone esterne, per questo stiamo pensando di passare a git perche' sembra piu' adatto in questo tipo di situazioni, ma siccome cambiare CVS e' un passo importante vi chiedo se avete esperienza con git (io lo uso giusto per manutenere alcuni repos su github) se il cambio vale la candela, quello che ci serve:

- definire tag o versioni o qualsiasi cosa in modo che si possa continuare lo sviluppo ma continuare a creare deployment riferiti alla versione "stabile"
- controllo di quello che va "live"
- gestire branch
- essere alla moda per fare il bello al Bar.. ahah .. no questo, no

Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a passare da svn a git

Grazie

J.

g4b0

unread,

May 10, 2013, 11:56:42 AM5/10/13

to

On 10/05/2013 16:20, Jeff wrote:
> Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a passare da svn a git

Nessuno. Praticamente tutto il mondo open source č passato a git, un
motivo ci sarą :)

Io sto collaborando ad un progetto open
(https://github.com/silverstripe/sapphire) hostato su github, č
spettacolare. Considera che siamo almeno un centinaio di persone a
collaborare, anche se non so esattamente a quanto ammonti questo dato.

--
g4b0, linux user n. 369000
http://brosulo.net

Alessandro Pellizzari

unread,

May 10, 2013, 12:51:59 PM5/10/13

to

Il Fri, 10 May 2013 07:20:22 -0700, Jeff ha scritto:

> La situazione sara' di avere piu' persone in ufficio ed anche piu'
> persone esterne, per questo stiamo pensando di passare a git perche'
> sembra piu' adatto in questo tipo di situazioni, ma siccome cambiare CVS
> e' un passo importante vi chiedo se avete esperienza con git (io lo uso
> giusto per manutenere alcuni repos su github) se il cambio vale la
> candela, quello che ci serve:

Dipende dai casi. Ma andiamo per punti.

> - definire tag o versioni o qualsiasi cosa in modo che si possa
> continuare lo sviluppo ma continuare a creare deployment riferiti alla
> versione "stabile"

Sì. git permette anche di fare diverse cosette che cvs/svn non consentono.
Per esempio, metti che sei in un branch di sviluppo, stai lavorando a
delle feature, ti chiamano e ti dicono "entro 2 ore devi fare questa
modifica in tutti i branch", ma tu hai le tue modifiche a metà che in
questo stato spaccano tutto.
Puoi fare un "git stash" e praticamente trasformare in un nuovo branch
tutto quello che hai fatto finora, fare la patch, pusharla e poi
riprendere dal tuo stash.
In pratica un "branch postumo". :)

> - controllo di quello che va "live"

Questo dipende dalla politica che adottate.

> - gestire branch

E` anche esagerato, da questo punto di vista.

> - essere alla moda per fare il bello al Bar..

Beh, alle conferenze di programmatori ruby farai sicuramente bella
figura. ;)

> Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a
> passare da svn a git

Partiamo da questi.

Se prendi la codebase e brutalmente la "gitti" perdi tutta la history del
svn. Ci sono dei tool che consentono di trasformare un repository svn in
uni git, ma non li ho mai provati. Ho sempre iniziato progetti nuovi in
git.

Il secondo è che ogni progetto è un repository a sé. In svn (e cvs) puoi
avere un singolo repository e scaricarti e lavorare sul singolo project
senza influenzare gli altri. In git, quando forki, forki tutto il repo,
quindi ti trovi in locale tutti i progetti, se ne metti più di uno nello
stesso repo.

Il terzo, collegato al secondo, è che gestirsi un "server git" con queste
premesse è un bagno di sangue, quindi è economicamente e sanitàmentalmente
preferibile pagare github o bitbucket (che offre repo privati gratuiti
fino a 5 sviluppatori, se interessa ;) piuttosto che installarselo e
gestirselo.
Corollario: se ti serve un account su bitbucket, chiedimelo, così ti
mando l'invito e guadagno, forse guadagnamo entrambi, un utente in più
sui miei repository :D)

Andando avanti coi difetti, gestire degli hook (pre e post-commit, push,
branch, ecc.) è molto più complesso, data la natura decentralizzata del
tutto. Rischi di fare degli hook che funzionano solo sulla tua macchina
ma non sul repo centrale o sui repo degli altri utenti.

Infine ultimo: essendo decentralizzato è necessari capirlo bene per
sfruttarlo bene. E il fatto che ci siano fior di articoli online sul
"best git workflow" ti fa capire che non c'è ancora un vero best git
workflow, perché è talmente flessibile che va adattato a ogni situazione.

Un esempio banale: hai il progetto su github, lo cloni in locale, fai un
branch (per non lavorare sul "trunk" che qui si chiama master) e inizi le
tue modifiche. Man mano che funzionano le committi, e a fine giornata le
pushi su github. Vai a casa, ti viene in mente un bug del cacchio (-1 al
posto di +1 in una riga) che hai introdotto e pensi "clono qui, correggo,
pusho e così non me ne dimentico domani mattina".

Cloni e... non c'è il tuo branch!!

Questo perché è decentralizzato. Ogni clone del repo è un server, quindi
i branch di uno non necessariamente sono sugli altri nodi.

Soluzione: il giorno dopo, in ufficio, pushi il tuo branch su un branch
remoto su github e poi sei a posto.

Ecco cosa intendevo quando dicevo che il supporto ai branch è anche
troppo spinto.
Tu in locale puoi fare branch senza preoccuparti che vadano a interferire
coi branch degli altri, anche se hanno lo stesso nome, perché tu in
realtà hai un repo locale totalmente scollegato dagli altri. Se vuoi
branchare su un altro repo remoto, devi creare il branch sul remoto, e a
quel punto ti avvisa se ce n'è già uno con lo stesso nome.

Va quindi decisa una politica di naming dei branch sul repo "centrale",
ma devi farla comunque anche con svn. L'importante è riuscire ad
abituarsi a pensare in "repo locale" e "repo remoto".

Se pensi che tutta questa potenza ti salvi dai conflitti, scordatelo.

Se lavorate in due allo stesso file, modificando le stesse righe, o se lo
modificate tanto che l'algoritmo di merging non riesce a ricostruire la
diff, avrai esattamente la stessa situazione di svn al merge.

Il vantaggio di git è che, essendo branch locali, spinge a fare micro-
commit continui.
Mentre in svn sei abituato a committare solo quando hai finito di
implementare una certa funzionalità (non importa quanto grossa) o a fine
giornata giusto per andare sul sicuro, con git dovresti committare il più
spesso possibile. Anche ogni 5-10 minuti. Ogni funzione che crei, ogni
file che modifichi, committa.

Questo ti porta a sfruttare la potenza di "git bisect".

Esempio: lavorate in 3 su un progetto, per una settimana di fila. Lo
finite e vi accorgete che, quando lo lanciate, il DB si spacca (spero
foste sul server di test :P). Guardando il codice non capite cosa stia
succedendo, e allora fate un "git bisect" indicando la versione in cui
sicuramente funzionava, e l'ultima committata/pushata. Lui recupera
quella in mezzo. La lanciate. Se il programma si spacca gli dite "era
corretta prima", se funziona "era corretta anche dopo", quindi continuate
di bisect finché non trovate le due versioni consecutive tra cui il
software spacca e non spacca. Analizzando il diff tra le due vedete dov'è
il bug. E con "git blame" sapete anche chi ha introdotto la modifica che
spacca tutto. :)

Consiglio, tempo permettendo, di prendere un sideproject e provare a
partire da zero con git per prenderci mano. Ci vorrà più tempo, ma almeno
non rischiate su codice di produzione.

Bye.

g4b0

unread,

May 13, 2013, 2:54:38 AM5/13/13

to

On 10/05/2013 18:51, Alessandro Pellizzari wrote:
> "git bisect"

Questo non lo conoscevo, che potenza git!!

Jeff

unread,

May 14, 2013, 6:52:55 AM5/14/13

to

Il giorno venerdì 10 maggio 2013 17:51:59 UTC+1, Alessandro Pellizzari ha scritto:
> Il Fri, 10 May 2013 07:20:22 -0700, Jeff ha scritto:
>
>
> > La situazione sara' di avere piu' persone in ufficio ed anche piu'

> > [...CUT...]

> > candela, quello che ci serve:
>
>

Grazie a tutti delle risposte,

@g4b0: In effetti il fatto che tutti stiano passando a GIT ci ha fatto pensare di fare il passo, soprattutto per gestire un gruppo che si sta allargando e con svn stiamo impazzendo ... tra l'altro proprio ieri ci ha generato un tree conflict (in un file che non abbiamo mai spostato, credo) che per risolvero abbiamo perso alcune modifiche.

Per essere onesto devo dire che alcuni problemi con svn sono dovuti agli IDE che usiamo non a svn stesso, netBeans e phpStorm, che salvano i cambiamenti delle cartelle fatti da riga di comando (giustamente) e mentre phpStorm sembra beccarci di piu' (esempio: sposto un file, lo modifico, poi mi accorgo che nulla funziona e lo rimetto dov'era, lo marca come modificato), netBeans fa cose un po' piu' a caso (nello stesso caso marca il file da cancellare, poi da aggiungere)

@Alessandro Pellizzari

> > - controllo di quello che va "live"
>
> Questo dipende dalla politica che adottate.
>

Intendo che ogni sviluppatore ha il proprio repo in "locale", poi ci sono i vari repo "remoti" (testing, staging, live) quando qualcuno da locale "committa" troppo conoscitore di git) sarebbe utile che per accettare il commit qualcuno (tipo il project manager) autorizzi questa cosa, soprattutto per passare dagli ambienti testing -> staging -> live.

Non so nemmeno se sia possibile.

>
> > - essere alla moda per fare il bello al Bar..
> Beh, alle conferenze di programmatori ruby farai sicuramente bella
>
> figura. ;)
>

E questa e' la ragione piu' importante, quindi credo passeremo a git :)

> > Ma soprattutto mi interesserebbe capire se ci sono impatti negativi a
> > passare da svn a git
>
>
>
> Partiamo da questi.
>
>
>
> Se prendi la codebase e brutalmente la "gitti" perdi tutta la history del
> svn.

Ottimo punto, potremmo lenirlo passando a git subito dopo una release cosi da essere stabili, mantenendo up il server svn cosi' eventualmente recupereremmo da li' cose che eventualmente servissero.

> Il secondo è che ogni progetto è un repository a sé.

Ok, questo direi che una volta abituatecisi, e' perfino meglio. Ordine! :)

>
> Il terzo, collegato al secondo, è che gestirsi un "server git" con queste
> premesse è un bagno di sangue, quindi è economicamente e sanitàmentalmente
> preferibile pagare github o bitbucket (che offre repo privati gratuiti
> fino a 5 sviluppatori, se interessa ;) piuttosto che installarselo e
> gestirselo.

Questo e' un punto chiave, gia' sento il management: "Il codice ce lo teniamo in casa ...", ma alla fine della fiera coi repo privati siam sicuri, giusto?

Comunque basta leggere

>
> Corollario: se ti serve un account su bitbucket, chiedimelo, così ti
> mando l'invito e guadagno, forse guadagnamo entrambi, un utente in più
> sui miei repository :D)
>

Si questo serve di sicuro.

Per i repo privati e' meglio github o bitbucket, o e' a simpatia?

>
> Questo ti porta a sfruttare la potenza di "git bisect".
>
>

E questo mi piace ...

>
> Consiglio, tempo permettendo, di prendere un sideproject e provare a
> partire da zero con git per prenderci mano. Ci vorrà più tempo, ma almeno
> non rischiate su codice di produzione.

Consiglio sensato!

>
>
>
> Bye

Grazie

Ciao!

Andrea D'Amore

unread,

May 14, 2013, 7:49:04 AM5/14/13

to

In article <14a70145-2c53-4cba...@googlegroups.com>,

Jeff <mr.s...@gmail.com> wrote:

> @g4b0: In effetti il fatto che tutti stiano passando a GIT ci ha fatto
> pensare di fare il passo, soprattutto per gestire un gruppo che si sta
> allargando e con svn stiamo impazzendo

Dato che siete già su svn hai pensato a passare a mercurial invece che a
git? L'organizzazione e di conseguenza i nomi dei comandi sono simili.

> Intendo che ogni sviluppatore ha il proprio repo in "locale", poi ci sono i
> vari repo "remoti" (testing, staging, live) quando qualcuno da locale
> "committa" troppo conoscitore di git) sarebbe utile che per accettare il
> commit qualcuno (tipo il project manager) autorizzi questa cosa, soprattutto
> per passare dagli ambienti testing -> staging -> live.

Direi di sì, basta che il repository principale sia gestito dai project
manager che devono poi vagliare i diff rispetto ad uno dei repository di
livello più basso e farne il commit.
Su github lo puoi fare con le "pull request".

> E questa e' la ragione piu' importante, quindi credo passeremo a git :)

Io sto cercando di usare fossil quando posso.

> Ottimo punto, potremmo lenirlo passando a git subito dopo una release cosi da
> essere stabili, mantenendo up il server svn cosi' eventualmente recupereremmo
> da li' cose che eventualmente servissero.

Ci sono gli strumenti di migrazione svn-git che importano anche la
storia.

> Per i repo privati e' meglio github o bitbucket, o e' a simpatia?

Github ha acquisito molto "momentum" (cioè quantità di moto) ultimamente
proprio per la rapidità di fare fork, l'intefaccia abbastanza gradevole
e il fatto che parte della struttura è essa stessa opensource.
Bitbucket ha alle spalle atlassian e da quello che leggo gli utenti
"avanzati" lo reputano più maturo e feature-rich, io non sono abbastanza
avanzato da notare le differenze, uso bitbucket per i repo privati e
github perché alcuni progetti che mi interessano usano quello.

Alessandro Pellizzari

unread,

May 14, 2013, 11:22:50 AM5/14/13

to

Il Tue, 14 May 2013 03:52:55 -0700, Jeff ha scritto:

> Per essere onesto devo dire che alcuni problemi con svn sono dovuti agli
> IDE che usiamo non a svn stesso, netBeans e phpStorm, che salvano i
> cambiamenti delle cartelle fatti da riga di comando (giustamente) e
> mentre phpStorm sembra beccarci di piu' (esempio: sposto un file, lo
> modifico, poi mi accorgo che nulla funziona e lo rimetto dov'era, lo
> marca come modificato), netBeans fa cose un po' piu' a caso (nello
> stesso caso marca il file da cancellare, poi da aggiungere)

Questo è un problema un po' con tutti i sistemi di controllo versione, e
l'unica soluzione vera è gestire la cosa da linea di comando.

Diciamo che git, col suo "committa sempre" allevia la cosa, perché non
vede i file come path nel progetto, ma come hash in un calderone, e nei
metatag dell'hash c'è anche il path, quindi spostare un file significa
solo cambiargli un metatag, non spostarlo fisicamente. Anzi, sono due hash
diversi, quindi non conflittano praticamente mai. :)

Ti posso dire che l'integrazione di phpStorm con git è ottima e non mi ha
mai dato problemi con file spostati, rinominati o altro.

> Intendo che ogni sviluppatore ha il proprio repo in "locale", poi ci
> sono i vari repo "remoti" (testing, staging, live) quando qualcuno da
> locale "committa" troppo conoscitore di git) sarebbe utile che per
> accettare il commit qualcuno (tipo il project manager) autorizzi questa
> cosa, soprattutto per passare dagli ambienti testing -> staging -> live.

Io farei un repo unico remoto con i branch testing, staging, live, in cui
solo il "git master" ha permesso di scrittura.

Gli sviluppatori clonano (sempre in un repo remoto che chiameremo
"dev1repo") il repo "centrale" (github lo chiama "fork") che chiameremo
"mainrepo", e poi ri-clonano in locale il loro dev1repo.

In questo modo possono committare e creare branch in locale quando
vogliono.

Una politica potrebbe essere:
- branch locale "nuovafeature"
- commit, commit, commit, ...
- feature finita: push nuovafeature dev1repo/nuovafeature
- entrano in mainrepo e fanno una pull request di dev1repo/nuovafeature

A questo punto il gitmaster riceve una pull request, va a controllarla, e
decide se fare il merge (nel branch development o in quello testing, per
esempio) o aprire un bug allo sviluppatore.

Una volta che decidete per il deploy, gitmaster va in mainrepo/testing,
fa un git merge mainrepo/development, e poi va nella macchina di testing
e fa un git pull del branch mainrepo/testing (idem nella macchina staging
fara "git pull mainrepo/staging", ecc. Sintassi esemplificativa e non
precisa ;)

Premettendo che questo l'ho ipotizzato a livello teorico, ma non l'ho mai
messo in pratica. :)

Ecco cosa intendevo quando dicevo che la politica è un po' complicata da
pianificare. :)

>> Il secondo è che ogni progetto è un repository a sé.
>
> Ok, questo direi che una volta abituatecisi, e' perfino meglio. Ordine!
> :)

Il lato negativo è che quando arriva un nuovo utente devi mettere la sua
chiave pubblica ssh su ognuno dei repo.

Se avete 4-5 progetti e lavorate sempre a quelli va anche bene.
Dove sono io abbiamo, ad oggi, circa 250 progetti (quasi 2/3 morti, oggi)
in un repo cvs, e ne nasce uno nuovo alla settimana (in media).
A questi livelli o automatizzi tramite script il "deploy/delete delle
chiavi ssh" o diventi matto.

>> Il terzo, collegato al secondo, è che gestirsi un "server git" con
>> queste premesse è un bagno di sangue, quindi è economicamente e
>> sanitàmentalmente preferibile pagare github o bitbucket (che offre repo
>> privati gratuiti fino a 5 sviluppatori, se interessa ;) piuttosto che
>> installarselo e gestirselo.
>
> Questo e' un punto chiave, gia' sento il management: "Il codice ce lo
> teniamo in casa ...", ma alla fine della fiera coi repo privati siam
> sicuri, giusto?

C'è un contratto dietro, si pagano dei soldi, quindi presumo ci sia anche
una tutela legale non indifferente, trattandosi di "core business" dei
loro clienti. D'altronde lo stesso problema ce l'hai coi server in cui
pubblichi il codice, e lì hai anche i database coi dati di terzi. :)

>> Corollario: se ti serve un account su bitbucket, chiedimelo, così ti
>> mando l'invito e guadagno, forse guadagnamo entrambi, un utente in più
>> sui miei repository :D)

> Si questo serve di sicuro.

Mandami una mail con l'indirizzo email in cui vuoi ricevere l'invito. :)

> Per i repo privati e' meglio github o bitbucket, o e' a simpatia?

A simpatia. Dovresti vedere le varie configurazioni e decidere, in base
alle dimensioni della codebase e al numero di sviluppatori, quale
conviene economicamente.

Bye.

P.S.: Da domani sono al JSday/PHPday fino a sabato sera, quindi
difficilmente risponderò sul ng, ma le mail dovrei riuscire a leggerle.

Alessandro Pellizzari

unread,

May 14, 2013, 11:23:26 AM5/14/13

to

Il Tue, 14 May 2013 03:52:55 -0700, Jeff ha scritto:

> Per essere onesto devo dire che alcuni problemi con svn sono dovuti agli
> IDE che usiamo non a svn stesso, netBeans e phpStorm, che salvano i
> cambiamenti delle cartelle fatti da riga di comando (giustamente) e
> mentre phpStorm sembra beccarci di piu' (esempio: sposto un file, lo
> modifico, poi mi accorgo che nulla funziona e lo rimetto dov'era, lo
> marca come modificato), netBeans fa cose un po' piu' a caso (nello
> stesso caso marca il file da cancellare, poi da aggiungere)