Newsgroup: it.comp.os.dibattiti
Titolo: [OT] Posso chiedervi un consiglio ?

Scusatemi, vi volevo chiedere un consiglio su una cosa.
Supponiamo che ci sia un team di sviluppo composto da
vari sviluppatori in diversi zone del mondo.
Si dividono i compiti, e ciascuno di questi sviluppatori deve
lavorare sul medesimo programma.
Uno si occupa di creare una certa procedura, l'altro si
occupa di crearne un'altra e così via.
Finquando lavorano su sezioni più o meno indipendenti,
possono anche lavorare sugli stessi sorgenti: il problema
però sarebbe avere un sistema di SVN accessibile via
Internet che permetta a tutti di avere sempre l'ultima
versione con le ultime patches, in modo che se uno
fornisce la patch X, questa venga immediatamente
salvata nelle copie dei sorgenti sull'hard disk degli n
sviluppatori.
In altre parole, si vuole che gli sviluppatori possano lavorare
in modo indipendente, ma allo stesso tempo si vuole che i
sorgenti del progetto su ogni hard disk di ogni sviluppatore
siano sempre sincronizzati.
Che programmi usereste? Che strategie adottereste ?
Lo chiedo qui perchè so che in questo campo avete più
esperienza di me.
Ciao e grazie
Pegasus

 Che programmi usereste? Che strategie adottereste ?
Moh... posso dire una cacchiata, o non capire cosa chiedi,
ma qualcosa tipo CVS?
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam al contrario, e cambia nazione
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen


Tipo, solo che vorrei qualche bel software che
rendesse il tutto semplice e comodo da usare.



Ti consiglio SVN, che tu stesso hai citato.
Con SVN vai sul sicuro ed è probabile che la caratteristica di aggiornamento
immediato che richiedi in realtà tu non la voglia :)
E' multipiattaforma e se lavori sotto Windows c'è l'ottimo TortoiseSVN.

 ma qualcosa tipo CVS?
Ha già parlato di SVN, non è li il punto.

 esperienza di me.
Ti confesso che non sei stato chiarissimo. La scelta di SVN come sistema di
version control è ottima (anche perchè senza alcun sistema di vc quello che
volete fare è un incubo).
Vorrai quindi dei programmi per interagire con il server svn. Dipende dalle
piattaforme. Se qualcuno dei tuoi utenti utilizza MacOS X, per esempio, la
scelta potrebbe cadere su TextMate (un editor di testo 'power' che appunto
include supporto per svn, oltre che per svariati altri sistemi di vc).
Se state lavorando con Java, e usate Eclipse, Eclipse ha un ottimo plugin
che si spupazz svn. E ne ha pure uno per cvs, se è per quello. Se usate
NetBeans, credo che anche li ci sia il supporto almeno per cvs, forse anche
svn ormai.
Se usate C/C++ potete pure usare Eclipse. Se è roba Windows, suppongo che i
visual studio abbiano qualche sistema per interfacciarsi a svn. 
Emacs ha supporto per svn tramite un modulino. Gli utenti di vim di solito
sono più shellosi e preferiscono il client cli. Insomma, questo dipende da
voi.
Ah beh, non ho considerato che potreste essere in vena masochista e usare
PHP. In tal caso più che suggerire TM su MacOS X (per il semplice fatto che
lo conosco e so che ha sia svn che php) non posso fare. E' da un bel po'
che ho scelto la vita, e non ho la minima idea di come siano messi gli
ambienti per PHP. Beh, se usi Emacs il discorso è uguale a prescindere dal
linguaggio. Idem per Eclipse, che immagino abbia un'estensione per PHP.
Per le strategie, bisogna vedere le vostre skills e tutto. E' molto
difficile dare un consiglio sulla base di nulla. Personalmente suggerirei
di adottare quelle metodologie agili che sono applicabili con team
distribuiti geograficamente e senza possibilità di meeting etc etc etc
(eventualmente cercando di colmare il gap con videochat e simili).

 esperienza di me.
SVN e` buono perche` lavora off-line, mentre CVS per un diff richiede 
la rete. SVN non e` pero` sincronizzato in modo automatico con un 
repository, va fatto a manovella.
Direi di rimanere con svn+ssh, ed eventuale modulo apache per vedere e 
scaricare il repository via web per gli anonimi.
-- 
Sensei <senseiwa@Apple's mail>
Haiku of the month:       Three things are certain
                          Death, taxes, and lost data
                          Guess which has occurred.

 possono anche lavorare sugli stessi sorgenti: 
Ciao Pegasus,
il problema qui non risiede nella scelta del Version Control software, 
fanno tutti piu' o meno lo stesso lavoro ma su come utilizzarlo.
Ti consiglio innanzitutto di stabilire come obbligatorio il check-in 
degli unit test insieme al software oltre che al check in del log dello 
static analysis tool che gli sviluppatori devono eseguire sul codice.
Poi e' importante che gli sviluppatori, specialmente se sono inesperti, 
capiscano l'importanza di non rompere (break) la build e definisci una 
procedura nel caso cio' accada ad esempio il developer potrebbe dover 
mandare una spiegazione del motivo per cui il suo checkin ha rotto la 
build a tutto il team (normalmente e' un buon deterrente).
A che cadenza la nuova build viene creata? Giornalmente? Basandoti su 
questo dovresti stabilire un checkin time limit su un ramo del tree 
prima che la build venga eseguita.
Ti consiglio vivamente di leggerti un qualsiasi Traditional Software 
Project Management book.
Saluti,
Bluff
-- 
Work is the curse of the drinking classes.
-Oscar Wilde

 E' multipiattaforma e se lavori sotto Windows c'è l'ottimo TortoiseSVN.
anche git non è male, lo sto sperimentando ultimamente e devo dire che è
veramente flessibile.

 veramente flessibile.
Si, Git in teoria potrebbe fare anche gli "aggiornamenti immediati" che
chiedeva Pegasus (git push) ma se non ha esperienza con questo tipo di tool
forse è meglio che inizi con qualcosa di più "tradizionale" :)

 forse č meglio che inizi con qualcosa di piů "tradizionale" :)
ah si su questo nessuna obbiezione.
solo perň conviene forse perderci un pň di tempo subito, che non dovere
fare una "trasmigrazione" verso qualche altro sistema dopo.
Non parlo solo di git, ma č un discorso generale.

 Che programmi usereste? Che strategie adottereste ?
Ti serve un sistema di source control distribuito? Io consiglio
Mercurial.
Mercurial però è velocissimo:
http://indico.cern.ch/contributionDisplay.py?contribId=29&sessionId=49&c
onfId=44
altrimenti basta SVN come ti hanno consigliato gli altri
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 Mercurial.
Ti va di parlarmene diffusamente? Nel senso che della 'velocità' mi frega
relativamente. Su progetti 'grossi' non ho tipicamente il potere di
cambiare vcs e sulla roba mia, il numero di files coinvolti è piccola (e
gli accessi sono locali).
Mi interessavano features, facilità di configurazione, esperienza
diretta...

 diretta...
Passo la palla a Valentino, è lui quello che lo usa day by day. Io mi
son trovato abb. bene ma preferisco il modello centralizzato al bazaar
:D


 Che programmi usereste? Che strategie adottereste ?
Allora, escludendo un modo automatico, per un progetto che sto svolgendo al
lavoro facciamo così:
1) Repository SVN con un branch principale che contiene il codice corrente con
alcuni tag per marcare le varie releases.
2) ogni sviluppatore/team ha un branch (nello stesso repository)
in questo modo c'e' sempre una versione aggiornata del codice che ogni branch
può sincronizzare con operazini di merge, mantenendo i branch indipendenti
concentrando il lavoro sui singoli aspetti a cui si stava lavorando.
Poi ovviamente quando ogni team/sviluppatore vuole pubblicare il suo codice, fa
un merge dal suo branch a quello principale.
In questo modo le probabilità di imputtanare il branch principale è molto basso.
Si è scelto SVN perchè è supportato da molti ide, altrimenti io avrei preferito
utilizzare bazaar o svk.

 :D
Adesso vediamo se tira in porta :P
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 wrote:

Beh innanzitutto un tree versionato con mercurial si puo` copiare a
destra e a manca copiando la directory. L'unico overhead e` nella
directory .hg nel root del tree versionato. Gira su windows, linux, osx,
freebsd ecc ecc. TextMate si integra benissimo, offline e` velocissimo,
online e` fulmineo. Un tree diventa versionato quando usi 
hg init dentro di lui.
Puoi rendere versionati ed esposti online una serie di directory figlie
di una prestabilita usando un file di configurazione che contiene ad
esempio:
[collections]
/usr/local/src/repos/ = /usr/local/src/repos/
Da questo momento in avanti quando aggiungi una directory versionata
tipo /usr/local/src/repos/foobar ti compare come
http://tuo.server.hg/foobar
 sul server.
Puoi dare alias agli url di push/pull in modo da fare, ad esempio:
hg push mario
o
hg pull mario
semplicemente aggiungendo al file .hg/hgrc del tuo checkout due linee
tipo:
[paths]
mario = 
http://tree.di.mario/mio_progetto
mario-push = ssh://us...@tree.di.mario//usr/local/src/repos/mio_progetto/
(si puo` anche usare il semplice https ma io preferisco ssh per il
vantaggio della chiave privata/pubblica e perche` e` piu` facile da
configurare secondo me).
Il merge utilizza programmi di terze parti (come ad esempio il FileDiff
di osx) per gestire i conflitti in modo rapido. 
E` distribuito e quindi si lavora completamente offline. Puoi firmare
digitalmente dei tag e verificarli con 2 comandi. Puoi gestire patch
queue come con quilt per fare in modo di lavorare su 'cose' diverse
anche se sono nello stesso file ma farne commit separatamente oltre che
lavorare sul progetto senza effettivamente cambiarlo, quindi puoi
de-applicarle tutte, fare l'aggiornamento del tree, ri-applicarle tutte
in ordine.
Il 90% delle volte il processo di sviluppo e`:
hg init [inizializzazione di un subtree]
hg addremove [aggiunge tutti i file nuovi e rimuove tutti i file che
c'erano ma ora non ci sono piu`]
hg commit -m "messaggio" [ovvio]
hg push
hg pull
hg update [le modifiche ottenute con pull vengono applicate al tree]
hg merge [due o piu` modifiche che partono dallo stesso nodo padre
possono essere unite per ottenere una nuova revision figlia di entrambe]
hg diff [per vedere i cambiamenti senza commit]
e altri meno frequenti. (ecc ecc)
-- 
Valentino Volonghi aka Dialtone
Blog: 
http://www.twisted.it/
Wii Code: 3069 7621 2175 6539
Friend Codes: 
http://www.consolerecords.it/forum/viewtopic.php?t=217

 destra e a manca copiando la directory. 
Ecco, già questo può bastare per uno switch. Uno dei miei problemi attuali
è che al momento attuale sviluppo su due macchine entrambe in dual boot. In
pratica significa dovere tenere sincronizzati due server oppure usare un
server in rete (ma questo è una rottura per roba grosso modo usa e getta).
Bene bene... esplorerò.