Newsgroup: it.lavoro.informatica
Titolo: Lavorare su due versioni della stessa applicazione

Salve,
di certo tra di voi c'è qualcuno che lavora su due versioni dello
stesso programma, magari una più incentrata sulla risoluzione bug (es.
1.2.3.4), l'altra sull'aggiunta di new features (es. 2.0.0.0).
Come automatizzate questo processo? Che tool utilizzate? Come fate il
merge del codice di bug fixing nella nuova versione? Quanto tempo vi
portano via le operazioni di merge?
Insomma, sono un po' a digiuno di queste cose, perdonatemi
l'ignoranza! :)

Piccola aggiunta: per ora usiamo VS2005 + SourceSafe e un unica
versione.

 l'ignoranza! :)
E invece IMHO e' piu' che un bene che tu ti faccia certe domande. 
Piccola citazione dal blog "Rand in Response" 
(
http://www.randsinrepose.com/archives/2004/07/10/what_to_do_when_youre_screwed.html
):
"There are an endless pile of tools engineers are fond of using in their 
development process, but there are only four that they really need:
     * Editor
     * Compiler
     * Version control
     * Bug tracking
I’ve never seen any engineering organization that hasn’t had some form 
of an editor and compiler, but I’ve been shocked to find both *version 
control* and bug tracking missing when I’ve walked in the door."
Ciao e buon lavoro,
Giulio
-- 
OnAir:
http://petrux.blogspot.com

 1.2.3.4), l'altra sull'aggiunta di new features (es. 2.0.0.0).
Due?!?! Al momento lavoriamo su 4 versioni (3 in manutenzione e una in
sviluppo) + una serie di versioni localizzate/personalizzate (su cui pero'
non mettiamo direttamente le mani).
Di silver bullet o formule magiche non ne abbiamo trovate, sinceramente.
A livello tecnico, si lavora con CVS (sarebbe meglio Subversion, ma e'
difficile cambiare le cose in aziende cosi grosse), e si fa il merge a
mano su tutte le versioni.
Quello che serve e' soprattutto tanta organizzazione e disciplina.
Il problema non e' tanto nel "come" si fa il merge, quanto nelle tecniche
che metti in pratica per evitare che la complessita' del processo faccia
degradare la qualita' del software.
Checklist delle cose necessarie per non impazzire:
- un buon bugtracker (meglio se con un API per essere integrato con tool
esterni) per tracciare tutti i bug, fix e change request
- resoconto automatizzato notturno di tutti i commit effettuati su i vari
branch, da mandare ai responsabili
- build automatizzata notturna di tutte le versioni
- deploy e test funzionali automatizzati notturni di tutte le versioni
- report di risultati di build e test automatici ogni mattina
- suite di unit test quando piu estese possibili
- tanta abilita' politica nel negoziare con i clienti le fix da includere
o no in ogni singola versione
-- 
Mopo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 :)
Manlio Perillo

 esempio Mercurial.
Esiste un tool tipo TortoiseSVN per utilizzarlo sotto Windows?
Ciao,
Giulio
--
OnAir: L'Aura - "I'm with you"
http://petrux.blogspot.com

 Giulio
Manlio Perillo

 puro (facendo tutto a mano da file system).
Aggiungo che tale tool risulta comunque *comodissimo* quando devi 
rinominare un file all'interno del progetto.
Ciao,
Giulio
-- 
OnAir: Sentenced - "Killing me, Killing you"
http://petrux.blogspot.com

 Esiste un tool tipo TortoiseSVN per utilizzarlo sotto Windows?
A me pareva che TortoiseCVS mi avesse devastato la macchina, quindi ho
pregiudizi per tutte le tartarughe ...
MS Source Safe va benino, ha di non funzionare su client non windows
CVS Va bene, anche se alcuni client non fanno il Lock esclusivo, il che puo'
andare bene ma ad alcuni non piace, e' una questione di filosofia
Per rispondere alla domanda iniziale in presenza di molte versioni il meglio
e' Rational ClearCase , che ha un livello in piu'. Si chiama il Delivery. Di
fatto serve appunto per gestire oltre al singolo file Una intera libreria,
cosi' si puo' scomporre la vostra applicazione in librerie, chesso',
"Kernel", una libreria "dati, grafica, ccetera. Si "deliverano" le librerie
comuni. I progetti a versioni o addirittura splttati del tutto potranno
essere aggiornati a blocchi di intere librerie ( scusa ma non e' per nulla
facile spiegarlo in 2 righe e non lo uso da 3 anni ).
Gli svantaggi di Clear Case sono 2 :
- Costa molto
- Aggiunge parecchia complessita', cosi' per usarlo bene bisognerebbe
1.programmare della formazione sul tool per chi non lo conosce,
2.Ci vorrebbe un buon sistemista che faccia da super admin ( puo'
addirittura essere usato in modalita' remota completa, cioe' con tutti i
file sul server ) ,
3. e per finire richiedee all'architect uno studio sul tool in modo da fare
bene il progetto delle librerie, e sfruttare il meccanismo del delivery.
quindi ponderare bene prima di utilizzarlo
Ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 l'ignoranza! :)
Purtroppo, data la natura del mio codice spesso poco OO proprio
laddove è suscettibile di maggiori modifiche, quando non ho una
snapshot CVS faccio tutto a suon di WinMerge amanuense, altrimenti in
presenza di versioning system utilizzo l'ottimo strumento di Eclipse
per il merge

 Ciao Nicola
Non sono d'accordo. A me sembra che le operazioni di clearcase siano
riportabili in operazioni di svn in questo modo:
- il join al progetto equivale a creare un nuovo branch
- il rebase equivale a mergiare le modifiche dell'head (o di un altro
branch) nel branch creato
- il delivery equivale a mergiare le modifiche del branch nell'head.
Per di più trovo che sia assurdamente scomodo e macchinoso da usare, e
molte funzionalità banali sono disponibili solo a linea di comando. Ad
esempio se voglio aggiungere al repositorio directory contenenti molti
file non posso aggiungere direttamente la directory ma devo aggiungere
tutti i file al suo interno (per confronto, in svn quando faccio l'add
di una directory se questa contiene qualcosa automaticamente vengono
aggiunti anche i file/directory al suo interno). Per fare un'altro
esempio ho dovuto scrivere uno script che usasse cleartool per sapere
se all'interno di una vista ci sono file che non fanno parte del
repositorio (al solito per fare un confronto con svn lì mi sarebbe
bastato fare uno status per vedere quei file marchiati con il ?).
Per me quindi clearcase andrebbe evitato come la peste.