Newsgroup: it.lavoro.informatica
Titolo: Gestione sorgenti

Come vi comportate ? Che usate ?
Io dalla tragica gestione a tre ambienti (DB, sorgenti e sistemi) non
sono mai riuscito a scappare :
- Sviluppo per le nuove versioni
- Patch per testare le correzioni in produzione
- Produzione
alle quali si aggiunge test in fase di rilascio della nuova release.
Ovviamente i sorgenti non sono completamente replicati ma dalla
necessità di riportare le patch in sviluppo non si scappa.

 sono mai riuscito a scappare :
sorgenti: quasi sempre gestiti con svn oppure attualmente con cvs(anche 
in sviluppo non in gruppo).
database: (fino a che applicativo non e' terminato) e' in un file di 
script sotto controllo di versione pure quello(a volte per sviluppare il 
db ci appoggiavamo a dei  design-tool).
Per gli aggiornamenti/patch tocchi un tasto dolente! :-D
Ne ho viste di tutti i colori patch e fix fatti a mano, 
innosetup(naturalmente implementavano sia aggiornamento db che files).
poi dipende da quanto durano i tuoi progetti ovviamente perche' se non 
devi poi mantenerli piu' non serve manco sbattersi piu' di tanto.
notte!

 necessit� di riportare le patch in sviluppo non si scappa.
Sui workflow di migrazione delle patch da versioni rilasciate a quelle 
in test e sviluppo ho cercato molte informazioni in passato ma non ho 
trovato ancora un workflow che ritengo semplice e valido...
proprio ora vorrei portare nel branch stabile di un progetto sotto svn 
alcune patch che nel trunk sono state marcate (nel changelog) come 
importanti e da integrare... l'unica soluzione "semplice ma manuale" � 
quella di trovare nel changelog il commit, creare un file di diff e 
applicare la patch sul branch corretto, ovviamente riportando a mano nel 
Changelog le varie modifiche. Nel mio caso la cosa si complica perch� ho 
convertito il repository svn in mercurial....

 trovato ancora un workflow che ritengo semplice e valido...
Idem.
Il mio è fai la patch nei sorgenti di test (che sono uguali a
produzione + patch non ancora passate)-> la testi allienando il DB a
produzione - > la rilasci in produzione. Poi devi riportare la
correzione nel main branch : a mano però, perché sono spesse incluse
modifiche al DB (dati e strutture).

 modifiche al DB (dati e strutture).
Esistono dei plugin per mercurial che ti permettono di semplificare i 
passaggi, aiutandoti a fare lo cherry-picking delle patch e a 
trasportarle in altri branch ma non l'ho mai usati...

 Come vi comportate ? Che usate ?
uso subversion + trac, ma quale strumento non è rilevante. fondamentale è 
avere chiaro il lifecycle e avere una procedura per gestirlo, poi lo 
strumento adatto lo trova.
riassumendo a grandi linee:
- lo sviluppo avanza sul trunk (o sull'head)
- ogni release viene taggata e viene aperto un branch
- le fix per quella release vengono fatte e rilasciate sul relativo branch
- il build è automatizzato (make, ant, maven, etc...)
- tramite trac traccio le richieste/bug e me le tiene collegate alle 
release, producendo il documento di release changes.
direi che non ci siamo inventati nulla, sono standard che più o meno 
tutti usano.

> - le fix per quella release vengono fatte e rilasciate sul relativo branch
E come le riporti sul trunk, in auto ?

 E come le riporti sul trunk, in auto ?
E vorrei ben vedere! :) svn merge fa al caso tuo solo che da shell e' 
un pelo ostico da usare
perche' devi prima cercare e poi specificare il range di revisioni da 
inglobare nel ramo.
mercurial e git sono piu' furbi perche' implementano il concetto di cloning del
repository. clone che e' implementato, se supportato dal SO, con hard link.
Hai il tuo bel repository locale che puo' essere clonato n volte per lo 
sviluppo in parallelo
e due comandi, push e pull, (a seconda di dove ti trovi) per inglobare 
i changeset.
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
Tempo fa hanno aggiunto la possibilita' di branching all'interno di un 
repository
e di recente il supporto alle sub repository. (che sono tipo gli svn:external)
Discorso diverso quanto diceva FP. Riportare uno o piu' changeset o 
peggio una parte
di esso da un ramo all'altro non e' proprio una passeggiata.
Mirko

 uso subversion + trac, 
Ci do un'occhiata, ho visto che con qualche spippolamento si pu� integrare
in Visual Studio 2008.
PaF

 E come le riporti sul trunk, in auto ?
con il merge. oppure replicandole, a seconda delle circostanze.

 trovato ancora un workflow che ritengo semplice e valido...
io credo dipenda molto dal numero e dalla eterogeneit� dei committers.
per quella che � la mia esperienza sono gli spostamenti dei change da un 
ramo all'altro le operazioni pi� complesse da gestire, per questo tendo 
a ridurli al minimo indispensabile.