2008/10/8 Fernando Vezzosi
<fv@linuxvar.it>
On Wed, Oct 08, 2008 at 06:17:13PM +0200, Walter Di Carlo wrote:
> Lavorare sullo stesso branch? Puoi spiegarti meglio.
Lavorare su una stessa directory?
Come specificato in
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.maint.layout subversion non impone alcun vincolo alla struttura del repository. Visto che il merge e' diventato molto piu' semplice perche' non creare un branch per sviluppatore+feature?. Noi per esempio usiamo chiamare i branch con
<nome_sviluppatore>_<nome_progetto>_<nome_feature>
Ovviamente nel nostro caso abbiamo preferito avere piu' progetti nello stesso repository
prjA
tags
prjA_verX1.Y1
prjA_verX2,Y2
branches
pippo_prjA_featureX
src
doc
res
pippo_prjA_bugP
pluto_prjA_featureX
pluto_prjA_bugZ
pluto_prjA_prova
trunk
prjB
....
Nota che sul trunk di ogni progetto ci teniamo la mainline ossia il risultato dei merge ufficiali, ma e' una nostra decisione. Questo ci pernette di rispondere in modo semplice alla domanda: Dove trovo i sorgenti piu' recenti per prjA? La risposta e' semplicemente prjA/trunk
La struttura dipende dalle necessita' e dalla complessita'. Nulla vieta' di citare i clienti nel rep. di subversion
ClienteA
prjA
tags
cA_prjA_verX.Y
branches
trunk
....
ClenteB
prjA
tags
cB_prjA_verX.Y
....
Tanto il costo nel repository delle varie versioni si riduce al costo delle solo differenze.
> Per quello che ne so io il costo di un branch e' molto ridotto. Quindi
> dovrebbe esserci un branch per sviluppatore.
Quindi c'è:
/progetto/tags/v1.0
/progetto/tags/v2.0
...
/progetto/branches/tizio
/progetto/branches/caio
/progetto/branches/sempronio
...
/progetto/branches/cliente_viziato
.. ? E poi ogni tanto si mergia tutto?
La politica di merge dipende da cio' che si deve fare. Se le funzionalita' su cui vari sviluppatori hanno molto in comune si fanno merge piu' frequenti. Pero' in questi casi bisogna anche capire se il progetto e le responsabilita' siano state suddivise nel modo piu' appropriato.
Ero rimasto ai feature branches :) Sai se qualche progetto open source
usa questa struttura? Così ci do un occhio.
Tutto dipende da cosa si intende per feature ;) Se con tale temine mi intendi un qualcosa che ha impatto su tutta l'applicazione nulla vieta di usare i feature branches. Certo che se mi fai un branch che si chiama GUI dove tutti ci devono lavorare forse e' meglio che lo consideri un altro progetto con relativi tags, branches e trunk
Prova a dare un occhio allo stesso Subversion (
http://svn.collab.net/viewvc/svn/ ;)
> Noi da quando abbiamo installato la 1.5 con il supporto del merge automatico
> facciamo i merge alla velocita' della luce ;).
Io sono rimasto alla 1.4, dove un merge tra due branch è un merge tra
due directory. Che cosa è cambiato? Ho letto qualcosa quando hanno
rilasciato la 1.5 ma non ho approfondito, è interessante.
Considera che tra la 1.4 e la 1.5 e' passato oltre un anno. In pratica hanno introdotto un tipo di merge molto simile a quello di GIT in cui viene considerato anche la storia del cambiamento. Il risultato e' che agli sviluppatori rimane da mergiare solo le parti in conflitto.
> > - I branch e i tags non sono altro che directory .. :)
> e quindi? non e' meglio?
Meglio che avere il supporto "vero" per i branch/tags? IMHO no. Non
dico che non funzioni, ma semplicemente mi sembra un pò sporca come
soluzione :)
Bho... continuo a non capire cosa intendi per supporto "vero" per i branch/tags? Secondo me cio' che conta, indipendentemente da come e' stato implementata la gestione, e quello di permettermi di esplicitare i checkout. Se ho necessita' di lavorare su due aspetti del progetto, mi creo due branch e me li checkout in due folder diversi. Per esempio potrei avere
Dev
pippo_prjA_featureX
pippo_prjA_bugP
Per esempio, in questo caso diventa molto semplice sapere da Vim su cosa sto lavorando. Per non parlare della semplicita' di fare gli 7-zip da distribuire ;) Ovviamente nulla vieta che lo stesso folder possa essere usato prima per sviluppare su un branch e poi su un altro. Io lo faccio, per esempio, perche' nel repository non abbiamo messo i file di configurazione dell'IDE. E quindi quando devo lavorare, per esempio con Eclipse, onde evitare di ricreare il progetto ad ogni switch, faccio il checkout sempre nello stesso folder
workspace
prjA
Ciao
Walter