Newsgroup: it.comp.os.linux.sys
Titolo: Ancora con i VCS

Ciao a tutti.
Sbaglio o il metodo corretto (o quanto-meno quello
piï¿œ sensato) per strutturare un progetto sotto VCS
ï¿œ quello di avere come "mainstrem" la versione
unstable, e dai li creare i branch testing e poi stable?
In pratica, stavo testando bazaar (giusto per provare,
per certi versi ï¿œ meglio di git, per altri peggio) ed ho
notato che facendo:
mkdir -p /mioprogetto/unstable
cd /mioprogetto/unstable
bzr init
touch primofile
bzr add
bzr commit -m 'Initial commit'
bzr branch . /mioprogetto/testing
cd /mioprogetto/testing
bzr branch . /mioprogetto/stable
strutturando questi livelli di branch
(unstable -> testing -> stable) ho notato
che basta fare un
bzr pull
per scaricare i commit fatti dal branch padre.
Potrei quindi lavorare sempre su unstable.
Quando vedo che tutto sembra funzionare, vado in
testing, faccio un pull e sperimento.
Se funziona, vado in stable, faccio il pull ed ho
finito.
Non bisogna fare i merge tra i rami.
Di conseguenza, posso smanettare a piï¿œ non posso su
unstable, fare tutti i sotto-branch che mi servono e
fare i merge dentro li. Poi vado avanti di gran pull.
E' corretto secondo voi?

 unstable, e dai li creare i branch testing e poi stable?
Mi sembra decisamente eccessivo, secondo me la cosa migliore secondo me
è avere UNA versione del programma e usare dei TAG per ogni release
stabile.
Avere branch di questo tipo serve solo a rompere le balle ai
programmatori, che diventano scemi ogni volta che fanno una modifica.
I commit devono essere piccoli, con test di tutti i tipi ad accertare
che non stai rompendo qualcosa, con il tuo sistema i programmatori
tenderebbero ad accorpare un sacco di roba volenti o nolenti (almeno io
farei così).
Io invece mi domando un altra cosa, per vari corsi ho un macro
repository in cui a mano mano ci piazzo dentro i progettini, tutto
questo con GIT.
Ora mi sono trovato a voler scrivere degli hooks solo per uno di questi
progettini ma la cosa non è fattibile, l'hook giustamente si esegue per
tutto il repository, quindi che fare?
Andare di submodules ogni volta?
Devo ancora capire anche come estrarre file da repository senza perdere
la storia e spostarli in altri repository, in generale come si dovrebbe
fare?

 Andare di submodules ogni volta?
Credo di si, tu in pratica hai creato un branch per ogni progettino
all'interno di un repository?
Non ti conveniva gestire tutto come submodules in modo da avere tutto
accorpato ugualmente ma con i vantaggi di un vero repository per ciascun
tuo progettino?

 e faccio il push.
Perï¿œ posso creare un branch a partire da un tag:
bzr branch -r tag:miotag . nomebranch
e poi fare il push di quello, che a quanto pare funziona:
cd nomebranch
bzr push prova
mi crea un branch prova (dato che non ho un server su cui pushare)
con il contenuto del brach creato in precedenza dal tag.
cosï¿œ facendo non si porta dietro l'intero progetto.

 farei così).
Però aspetta, forse mi sono espresso male.
La struttura a tre branch sarà "a cascata".
Gli sviluppatori lavoreranno sempre e solo su un branch,
ovvero quello unstable. Faranno tutti i loro commit li
sopra, grandi o piccoli che siano. Creeranno i loro branch
e faranno i vari merge, ma sempre nel ramo unstable.
Gli altri due per loro non esistono.
Sono io, che quando vedo che lo sviluppo diventa abbastanza
stabile, mi posiziono in testing e faccio il pull.
Considerato che testing è un branch di unstable, il pull
sincronizzerà automaticamente tutto il ramo testing scaricando
la unstable così com'è (oppure scaricando una tag precisa).
Sempre io, mi posizionerò su stable e farò un nuovo pull, il quale
scaricherà la testing.
Ai dev non cambia assolutamente niente, lavoreranno sempre e solo
su un singolo ramo, quello unstable, degli altri branch non gli
deve importare, tanto non possono accedere.
L'unica cosa che non mi convince di bazaar è che crea un directory
per ogni ramo, in pratica sporca la directory di lavoro con le
sue cose. SE io avessi in un progetto 40 directory (facenti parte
del progetto), creando i vari feature branch come suggerito da canonical
mi ritroverei nel giro di pochi minuti con centinaia di directory,
alcune del progetto, altre di bazaar. Mi sembra una stronzata.
Git fa tutto di nascosto, questo fa tutto alla luce del sole.
Non c'è una via di mezzo per la miseria?
Il problema di git è che il supporto per windows è decisamente
scarso e tutti i miei sviluppatori lavorano su windows. Bazaar
ha un finimondo di gui per windows, tra cui l'ottimo tortoiseebzr
ed altro e si installa direttamente, senza mingw.
E sopratutto, gestisce i file rinominati in automatico, git no.
(ed i miei dev rinominano spesso i file)

 tuo progettino?
Sì mi conveniva e infatti cercherò di farlo, ma non mi è ben chiaro come
tirar fuori la roba senza perdere la storia.
Una cosa che mi cruccia ad esempio è la mia configurazione di emacs:
https://github.com/AndreaCrotti/Emacs-conf/tree
In sostanza il .git è nella $HOME, e ora vorrei spostarlo in .emacs.d,
inoltre lì dentro ho anche molti file di altri repository oltre che alla
mia configurazione.
Quando aggiorno quelli ho dei grossi commit con magari niente di mio,
quindi vorrei separarli, ma allo stesso tempo vorrei che tutta la mia
configurazione sia replicabile e utilizzabile da me e da altri (c'è già
qualcuno che la usa) senza installare nient'altro.
Qualche idea?

 (ed i miei dev rinominano spesso i file)
Ok capito perché sei passato a bzr, che palle questo windows...
Comunque il rename dei file non so bene come funzioni con git ma li
trova anche lui.
A volte per sbagli li sposto con "mv" invece che "git mv" e al commit
dopo mi fa un semplice rename, che che semplicemente verifichi se il
nuovo file non è per caso uno che ha già.

 importare, tanto non possono accedere.
Questo funziona in alcuni casi, tipicamente quando non hai versioni 
"stable" da mantenere con bugfix segnalati dall'esterno.
Ma se devi mantenere una o piu` versioni stable (magari perche` a un 
cliente hai venduto la 1.0 e a un'altro la 2.0, e i tuoi programmatori 
stanno lavorando alla 3.0), coi branch ti trovi meglio, perche` fai il 
checkout del branch (diciamo 1.0), correggi l'errore (manualmente o con 
un merge da "unstable" o da "2.0") e ricommitti nel suo branch (1.0).
A quel punto potrai ridistribuire la 1.0 corretta a tutti i clienti che 
non vogliono/possono upgradare alla 2.0, e nel frattempo continui a 
lavorare sulla unstable per la nuova versione.
Bye.

 stanno nello sviluppo?
Era un esempio. Loro mi diranno quando l'applicazione è stabile ed io
pullo dal testing e dalla stable.
Però, considera che spesso i programmatori fanno gli operai da catena
di montaggio. Una cosa funziona in quel preciso momento e la considerano
stabile. Capita spesso che per fixare un bug ne creano altri 4, e
nonostante ciò lo considererebbero stable, perchè il bug è risolto.
Per prevenire questa cosa, abbiamo un reparto di "testing" fatto dai
commerciali, che testano l'applicativo e poi autorizzano ad andare
in stable.
Un po come quando scrivi un testo da molto tempo, a lungo andare gli 
errori presenti non li vedi più e conviene farlo leggere da altri.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 nuovo file non è per caso uno che ha già.
Il problema più grosso, purtroppo, non è come gestire lo sviluppo
del software, bensì come non rompere i coglioni ai programmatori
facendo eseguire comandi a destra ed a manca.
Devo (è un must) trovare un programma che sia gestibile da Eclipse
(Aptana per la precisione) e/o da gestione risorse di Windows.
Non posso dire ai programmatori: quando fai un feature branch apri
il prompt dei comandi, esegui git branch, bla bla bla, apri aptana,
lavora, apri il prompt, fai il commit, e tutte ste madonne qua.
So già che si rifiuterebbero di lavorare, giustamente.


 un merge da "unstable" o da "2.0") e ricommitti nel suo branch (1.0).
Questa delle versioni stable multiple capita sempre.
Quindi tu dici di avere un ramo di sviluppo, che contenga tutto.
Stable, unstable, testing, vattelapesca.
I dev lavorano. Esce la prima versione stable. Si tagga 1.0 e magari
si crea un branch a partire da tale tag, giusto per splittare i rami
di sviluppo.
Si continua a lavorare sul ramo principale. Esce la versione 2.0.
Si tagga.
Si crea il branch.
Si lavora alla 3.0. Esce, si tagga, si crea il branch.
Avrò così il "trunk" che sarà sempre l'ultima versione disponbile,
e teoricamente la più instabile.
A partire da tale trunk ci saranno i tag ed i rispettivi branch, creati
per comodità, basterebbe tenere anche solo i tag e creare i branch
di volta in volta.
Se il cliente con la 1.0 nota un bug, si apre (o si crea) il branch
associato al tag 1.0 e si fixa li dentro. si committa il branch.
Avrò quindi una 1.0.1.
Stessa cosa per eventuali bugfixing sulla 2.0 che diventeranno 2.0.1
Avrò così il ramo di sviluppo che sarà sempre quello principale e
tutti i vari branch.
MA: (perchè c'è sempre un ma)
cosa fare se nella versione 2.0.1 e nella 1.0.1 si scoprono dei bug
in comune? La base di codice potrebbe essere differente, per cui lo
stesso fix potrebbe non essere applicabile. In tal caso, si risviluppa
il fix anche per la 2.0.1, se applicabile senza rivoluzionare il tutto.
altrimenti si cerca di risolvere il bug nella prossima stable, magari
riprogettando intere sezioni.
Ma se il fix fosse compatibile tra le versioni, come posso fare a
copiare il fix fatto sulla 1.0.1 sulla 2.0.1? Conviene creare un
feature branch per ogni fix, partendo dalla 1.0.1 e fare il merge
di tale feature branch sulla 2.0.1 ?
Non si rischia di spaccare del codice facendo cosi?


 Non si rischia di spaccare del codice facendo cosi?
Il codice si spacca da solo (per esperienza personale) man mano che 
sviluppi nuove funzionalita`, soprattutto se insorgono esigenze non 
previste in fase di progetto. Rifattorizzi il codice, sposti funzioni, 
cambi le API, ecc. ecc. Prima o poi rompi qualcosa. :)
Bye.

 So già che si rifiuterebbero di lavorare, giustamente.
Secondo me un programmatore che si rifiuta di imparare a usare un VCS non 
e` un programmatore, ma al massimo un code monkey, e come tale va 
trattato (soprattutto a livello di stipendi :P)
Bye.

 writes:

Concordo, un programmatore dovrebbe sentire il bisogno di un VCS.
Dovrebbe rifiutarsi di lavorare se mai se sapesse che quello che scrive
NON è sotto controllo di versione.
Non è importante che diventino dei maghi, ma di sicuro devono capire
cos'è un branch, come funziona il merging, e tutti gli altri i concetti
basilari per riuscire a utilizzare in modo decente questi strumenti.
E possibilmente se fanno una piccola cazzata devono essere in grado di
rimediare (un revert ad esempio dopo aver cancellato per sbaglio un file).
Se non ne vogliono sapere mi sa che ti conviene cambiare programmatori
;)

 cambi le API, ecc. ecc. Prima o poi rompi qualcosa. :)
Vero, ma si cerca di spostare questa rottura il più in la possibile.
Un conto è spaccare il codice ogni volta ad ogni modifica, un conto
è spaccarlo solo in determinate occasioni, che magari riesci a
preventivare in anticipo.

 trattato (soprattutto a livello di stipendi :P)
Bene riformulo la domanda:
io lavoro in uno zoo, pieno di code monkey.
Come posso gestire al meglio le versioni di un software ? :)
Scherzi a parte, un conto è imparare il VCS, un altro conto è
ritrovarsi a dover fare 4-5-6 operazioni qunado prima ne bastava
uno.
Se fosse come dici te, tutti dovremmo programmare con il blocconote,
mentre invece fortunatamente si programma con degli aiuti.
Scommetto quel che vuoi che te ti rifiuteresti di lavorare ad un
progetto più grande di un "Ciao mondo" con il solo blocconote.
Per i VCS è uguale, se devi eseguire ad ogni cavolata 3-4 comandi
diventa un inferno. quello che prima facevi in 10 minuti di cui 9
di coding, ora lo fai in 20 di cui 15 di VCS.

 Se non ne vogliono sapere mi sa che ti conviene cambiare programmatori
non sempre è possibile.

 coding, ora lo fai in 20 di cui 15 di VCS.
No, aspetta, non ci stiamo capendo. :)
Il "come funziona un VCS" deve essere chiaro a un programmatore. Poi puo` 
trovarsi meglio con uno che con l'altro, ma deve capire come funzionano i 
branch, almeno in linea generale.
Poi Eclipse fornisce (splendidi) strumenti per facilitarti il lavoro. Io 
uso praticamente solo quelli sia per CVS che per SVN. Mi pare ci siano 
plugin anche per Git e/o Bazaar, ma non ci metto la mano sul fuoco.
Sono comodi perche` ti evidenziano nel file manager i file modificati, ti 
chiedono cosa fare durante un merge, e con due click "committi" le 
modifiche, e con altrettanti fai l'update della copia locale.
Puoi anche fare il checkout di un branch, stavolta con 4-5 click, giusto 
per selezionare quale vuoi nel tree. ;)
Ma se non hai le basi di come funziona, non sai nemmeno cosa significa 
"commit"! :)
Bye.

 2.0.1, mi ritrovo anche tutte le schifezze in fase di collaudo.
No, non devi fare il merge di tutto, ma solo del file errato.
Questo puo` introdurti qualche errore (per esempio se cambi l'API da una 
versione all'altra) o richiedere merge manuale, o addirittura, in certi 
casi, essere impossibile e richiedere la riscrittura manuale. Cosi` come 
(in presenza di piccole modifiche tra le versioni) essere completamente 
automatico.
In alcuni casi puoi anche confrontare (anche visivamente con Eclipse o 
con meld, per esempio) le due versioni del file, e fare il merge solo di 
alcune righe, invece che di tutto il file.
Dipende da quanto differisce il codice tra le due versioni. Non esiste la 
bacchetta magica. :)
Bye.

 "commit"! :)
Nessuno discute le basi. Quelle ci vogliono.
Io però sto selezionando un VCS (tanto fanno più o meno tutti la
stessa roba) in base ai tool ed agli aiuti a corredo.
Bazaar per ora è in testa.

 No, non devi fare il merge di tutto, ma solo del file errato.
E come diavolo si fa?
Non mi pare di aver visto tra i parametri del comando,
il file da mergere.

 agli aiuti a corredo.
Era un "tu" generico riferito ai programmatori scimmieschi, non a te 
direttamente :)
Bye.



Premetto che non mi e` mai capitato di farlo, ma da Eclipse clicchi col 
destro sul file, da li` Team->Merge... ti apre una finestra dove 
selezioni il branch, e abiliti il "Preview Merge in Synchronize View".
Questo con CVS, che ho sotto mano.
Bye.

 da sotto il naso.
guardato mercurial?
ti cambia i file solo quando gli dici di farlo e ha un .hg solo nella
root del progetto :D
(no, con eclipse non so come è integrato, so solo che c'è il plugin)

 direttamente :)
Lo so...


 root del progetto :D
In che senso cambia i file quando gli dici di farlo?
Quando fai il checkout di un branch presumo, in pieno stile
git.
Anche git li cambia quando fai il checkout...


 Anche git li cambia quando fai il checkout...
Ed è una cagata.
Supponiamo che io faccia il checkout di un branch su
una unità di rete condivisa (da windows).
Il primo che arriva mi modifica tali file, senza sapere
su quale branch sto lavorando.
Con Bazaar almeno sai sempre su cosa stai lavorando, apri
la directory che ti interessa e smanetti li dentro, senza
tirare ad indovinare.
Però ti sporca la working dir in maniera assurda.
(ma si possono sempre creare branch fuori dalla directory
di lavoro, come con:
$ pwd
/home/progetto/stable
$ bzr branch . /home/ciccio/miobranch
vado in /home/ciccio/miobranch e mi trovo il
mio bel branch, pronto da modificare come mi pare
o da comprimere e passare ad un amico.
git è più macchinoso da questo punto di vista, e
mercurial penso faccia uguale.


 mercurial penso faccia uguale.
E' per questo che esiste il file .git/HEAD.
Quello che dici tu semplicemente non si dovrebbe fare mai fare, o metti
su un server o ognuno si usa la sua working directory, non credo che
usare unità di rete condivise sia una buona idea.
E comunque se con emacs apro una directory con un repo git io vedo
subito in che branch sono, me lo dice senza bisogno che vada a cercarlo.
Questo sistema può essere pericoloso se non si usano gli strumenti
giusti ma non direi che è una cagata, è l'unico modo per non riempire la
directory dir roba che al momento non ti serve.

 directory dir roba che al momento non ti serve.
Basterebbe mettere tutto nella directory .bzr o studiare
un qualche altro modo.
Boh, è vero, ci si incasina con le directory, ma il metodo
di lavoro di bzr mi sembra più semplice ed intuitivo.
cd nomebranch ed ecco fatto.
non devi fare il checkout e far cambiare i file.
c'è anche da dire che se lavori in modalità distribuita, come
sarebbe giusto fare con tali strumenti, ogni dev in realtà
lavora in locale, per cui se cambia branch non da alcun problema
agli altri sviluppatori. i file cambierebbero solo nella sua copia
locale.
boh, devo fare delle prove con eclipse per capire bene quale strumento
è migliore.


 mercurial penso faccia uguale.
16:57:07 Wed Jan 20 raf@hal ~/src/django/django/django
django/default? $
17:00:51 Wed Jan 20 raf@hal ~/src/django/django/django
django/default? $ hg branches
default                    12074:0f786601ddef
releases/1.1.X             12072:f107947ba46c
soc2009/model-validation   11910:8c2a5d263ea1
releases/1.0.X             11817:d333eaa530cc
soc2009/multidb            11764:80e3954455a2
soc2009/admin-ui           11750:d5122c46cd7e
attic/unicode              11340:5cbdeab51742
attic/sqlalchemy           11338:f0babba57fcc
attic/search-api           11336:71f81f81a588
attic/schema-evolution-ng  11334:65ec6c923787
attic/schema-evolution     11332:a5d6449104aa
attic/queryset-refactor    11330:36810ac9acc7
attic/per-object-permissions 11328:64f2161fe6da
attic/newforms-admin       11326:b8e20a240e47
attic/new-admin            11324:7e40bab9217a
attic/multiple-db-support  11321:7490ab26bb96
attic/multi-auth           11319:7f56cda4e029
attic/magic-removal        11317:dcf1be1c63a4
attic/i18n                 11315:720f381800dd
attic/gis                  11313:9fceccaf95cc
attic/generic-auth         11311:2a8e9d54eca0
attic/boulder-oracle-sprint 11309:b7ba99188bf0
attic/full-history         11307:98d0e57fc3ae
soc2009/test-improvements  11282:a65581da7f4d
0.96-bugfixes              11275:a7f2c7b7c9ac
soc2009/i18n-improvements  11266:176fcae94b1f
soc2009/http-wsgi-improvements 11252:8f84bbfdaa6a
0.91-bugfixes               9472:f864a4b342dc
0.95-bugfixes               8707:12fca84b6f8e
0.90-bugfixes               4324:0e8f2e6872d5
17:00:55 Wed Jan 20 raf@hal ~/src/django/django/django
django/default? $ hg update -C soc2009/admin-ui
585 files updated, 0 files merged, 342 files removed, 0 files unresolved
17:01:45 Wed Jan 20 raf@hal ~/src/django/django/django
django/soc2009/admin-ui? $
In mercurial i branch sono nello stesso repository, non in parti di fs
diversi.

 diversi.
Non ho capito.
Mercurial dove ti salva i branch?
Se io creo un nuovo branch, mi fa una cartella o mi sposta
i file ad ogni checkout in stile git?
(anche in bazaar sono nello stesso repository, e ci mancherebbe
che non fosse così, ma è proprio questo il punto. Ti sporca
la directory, ma volendo c'è il modo di creare i repo 'fuori'
dalla working dir)


 dalla working dir)
Beh, se ti trovi meglio con bzr, se riesci ad avere un flusso di lavoro
più semplice, usalo. Sono fatti apposta :D
In verità non c'è (ancora) un sistema che va bene per tutti, indi per
cui si sceglie in base alla pelle .

 cui si sceglie in base alla pelle .
Lo so, le funzionalità sono uguali per tutti e tre.
Si va a gusti, purtroppo.

 selezioni il branch, e abiliti il "Preview Merge in Synchronize View".
Con Eclipse + Bazaar, posso fare il merge.
Prendo il branch che voglio mergere in nel ramo principale,
scelgo dal menu a tendina il ramo principale e vado avanti.
Lui fa il merge, ma è macchinoso.
1) non posso selezionare cosa mergere, ma fa il merge di tutto
2) in caso di conflitti, come nelle prove che sto facendo, da
errore e basta. mi dice: conflitto nel file xy.php, ma non mi da
modo di vedere l'output con le differenze.
Nel menu team non ho alcuna voce diff, per cui, non mi pare un
gran sistema, come faccio a vedere cosa cambia tra due progetti
prima di fare il merge?


Per come lavoro io il path non mi direbbe nulla.
Navigo tra i buffer aperti, e nella modeline vedo benissimo in quale
branch sto lavorando.
Comunque sì sono più o meno tutti uguali, ti basta trovare un modo
coerente per usarli.
Ma domanda stupida, ne hai parlato con gli sviluppatori? Avranno già
usato qualcosa nella loro vita e spero avranno qualcosa da dire in
generale...

 generale...
No, non hanno mai usato niente di simile.


 coerente per usarli.
Dissento fortemente.
Lo scopo si, hanno tutti lo stesso scopo. Ma nel farlo sono filosofie
completamente diverse.
Io con git mi trovo male, mentre con hg lo trovo quasi naturale.
Altri il contrario.

 Altri il contrario.
Oibò, potresti indicare perchè git non ti piace e mercurial si?
Sono quasi uguali.


 scarso e tutti i miei sviluppatori lavorano su windows
Hint: Mercurial
Enrico

 Enrico
Ci sarebbe anche darcs se sei in vena di esperimenti, ci sono un sacco
di documenti interessanti sulla teoria delle patch, tipo
http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory
Comunque oggi ho avuto un esempio di come non si lavora con un VCS.
Un mio compagno di gruppo invece di fare un "svn update" (purtroppo svn
sì) come la teoria vorrebbe si copia tutto da un altra parte
(brutalmente proprio, neanche rsync) e poi lavora su quello, nel
frattempo tu fai modifiche e lui se ne fotte o le butta dentro a mano.
Ora questo ritardato insieme all'altro ha lavorato tutto il giorno su
due revisione precedenti alla mia, SENZA FARE nessun commit, se non a
fine serata.
Risultato, mi sono trovato a mettere a posto gli stessi bug, poca roba
per carità ma girano comunque le balle.
Lo stesso personaggio mi ha chiesto perché uso la shell, e mi ha detto
di aver provato (in qualche corso del piffero immagino) che usare il
mouse è più veloce.
Il windowsianismo dà alla testa (usa pure kubuntu tra l'altro ma come se
fosse windows).

 fosse windows).
No, non esageriamo. Ci sono tools VCS anche per windows.
Il problema è lasciare accessibili i file anche da strumenti
non vcs, non il windows in se per se.

 Hint: Mercurial
Sto valutando anche quello.
Di bazaar, ad esempio, non sopporto il modo in cui
mi presenta i conflitti. Va a modificare i file
inserendo dei marker.
No no, non fa per me, i miei file li voglio modificare
io. Non mi piace sapere che un qualche programmino se
gli gira male mi modifica un file. se nel progetto
ci sono 2-3.000 file ho paura di andare dritto dritto
in mezzo a dei casini.
Mercurial ha il vantaggio (rispetto a git) di avere il
numero di revisioni umanamente comprensibile, cosa per
me fondamentale, in quanto ho bisogno di avere un
revision-number nella versione del codice.
Vedo che in moltissimi usano ancora il sistema centralizzato
per sviluppare software. Anche Zend, ad esempio, usa SVN
centralizzato. Probabilmente se si lavora dentro una
software house il centralizzato è migliore e meno confusionario
rispetto ad un distribuito. Ed in effetti, facendo prove,
il centralizzato è abbastanza intuitivo. Fai le modifiche, committi,
se non sei aggiornato pulli, controlli eventuali conflitti e
ricommitti.
Boh, non riesco proprio a trovare un modus-operandi corretto.
Sto facendo ogni tipo di prova possibile ed immaginabile, ma
non ne vengo a capo. Consigli? Suggerimenti? Hint ?

 non ne vengo a capo. Consigli? Suggerimenti? Hint ?
Bah, sicuramente gli utenti più scafati traggono molti più vantaggi da
un sistema distribuito, se sei proprio nella giungla cambia poco secondo
me...

 me...
Il centralizzato è più semplice da usare.
Ma se bisogna fare molti commit come suggerisci te, uno degli
sviluppatori si ritroverà per forza di cose a passare metà
della sua vita a fare il pull, perchè l'altro ha appena committato.
Però il sapere che il codice è in giro per tutti i computer mi
terrorizza, preferirei saperlo sempre e solo in un posto ben
preciso. Non mi va di far girare il codice per troppe postazioni.
(come vi proteggete dal furto di codice?)

 (come vi proteggete dal furto di codice?)
Io ti consiglierei di cominciare ad installare qualcosa anche a loro e
provare a farli lavorare su qualcosa di farlocco a tempo perso.
Magari qualcosa di divertente (barzellette al massimo) giusto per fargli
provare lo strumento e far capire a te come lo usano/userebbero.
Furto del codice dubito che si possa fare qualcosa, o meglio qualsiasi
cosa sia più o meno sicura renderebbe quasi impossibile lavorare...
Se uno non è completamente stupido può trovare 1000 modi di copiarsi il
codice, d'altronde ci sta lavorando su!

 provare lo strumento e far capire a te come lo usano/userebbero.
Vero, ma prima di farlo vorrei almeno trovare un sistema che
grossomodo possa andare bene. Non posso di certo far provare ai
programmatori 4 DVCS differenti, quando io per primo non ho idea
ne di quale usare, ne di come usarlo, sarebbe solo tempo perso.
Git è bello, molto bello, ed anche intuitivo.
In mezzora ho capito come usarlo, grosso modo. (almeno i comandi base).
Bazaar da un certo punto di vista è migliore, ma a logica mi sembra
più contorto. Mentre con git ho capito come lavorare, con bazaar son
3 giorni che smanetto ed ancora non ci ho capito quasi niente.
Però git ha come revisioni un hash, bazaar ha un numero incrementale,
cosa che preferisco di molto. (praticamente sto scartando git solo
per il metodo di numerazione, e per la non gestione delle directory
vuote, molto presenti nei nostri progetti)
Mercurial ha un numero incrementale, ma non gestisce ne directory vuote,
ne file rinominati. Bazaar lo fa automaticamente.
Boh, è il workflow che non riesco a trovare, non tanto lo strumento.


 Boh, è il workflow che non riesco a trovare, non tanto lo strumento.
Mercurial vs git:
http://www.straw-dogs.co.uk/11/16/mercurial-vs-git/
Io ho cominciato ad usare git solo per github, e per me va benissimo.
Per quanto riguarda il numero di revisione, ho trovato anche questo:
da "git help describe"
--8<---------------cut here---------------start------------->8---
With something like git.git current tree, I get:
    [torvalds@g5 git]$ git describe parent
    v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4, but
since it has a few commits on top of that, describe has added the number
of additional commits ("14") and an abbreviated object name for the
commit itself ("2414721") at the end.
--8<---------------cut here---------------end--------------->8---
Questo mi sembra più che sufficiente.
Non è numerato dall'inizio in automatico credo perché la storia può non
essere lineare (rebase e altre amenità) rendendo il tutto un delirio.
Per le directory vuote, beh il problema è a monte, a che diavolo
potrebbero mai servire delle directory vuote? E poi chettefrega in
sostanza?
Metti in testing qualcosa, i problemi verranno dopo, altrimenti non
inizi mai ;)

 inizi mai ;)
Ed è quello che farò, ma PRIMA di mettere in testing qualche cosa
devo aver capito almeno come ragionare nell'ottica di un VCS.
Ripeto: non sto cercando di capire quale sia migliore o peggiore
come strumento, per quel che devo fare sono tutti uguali (grossomodo).
Il più è capire come strutturare il lavoro tra 5 sviluppatori, i vari
branch, un repository centrale e così via.
E' un problema logistico.


 E' un problema logistico.
Fammi capire, quale sarebbe il problema delle directory vuote?
Vuoi che ti tenga traccia anche di quelle?
Ma che gliene frega in sostanza, quando uno aggiunge un file, viene
aggiunta anche la dir e stai a posto.
Francaemnte I problemi che hai tirato fuori sono o inesistenti o
facilmente aggirabili, l'unico vero problema è far entrare nella testa
dei programmatori come vanno usati questi sistemi.

 aggiunta anche la dir e stai a posto.
Abbiamo alcuni siti, i più vecchi, che utilizzano delle directory
vuote.
Ma ripeto, il problema non è tanto la directory vuota, quanto
la revisione sequenziale.



Alura, se lavorano decentemente avrai 100 commit in più al giorno
(vabbeh forse esagero un po' comunque tanti).
Di sicuro on ti interessa poter riferirti a tutti i possibili
mini-commit.
Una qualsiasi versione che vuoi consegnare va taggata a mano.
Potresti anche taggare in automatico ad esempio tutte le notti, sul
server
git tag nightly_$(date)
(o qualcosa del genere)
e tutti i commit del giorno dopo li puoi vedere con git describe
rispetto al nightly build.
Altrimenti usa hg se preferisci, ma scegli qualcosa e usalo :D

 Boh, è il workflow che non riesco a trovare, non tanto lo strumento.
Credo anche io.

 E poi chettefrega in sostanza?
Ma si può ovviare in n modi diversi, in base ai gusti, indi non è il
problema più urgente in un dcvs ;)

 Sono quasi uguali.
sono entrambi dcvs si, ma:
- git espone l'index, hg no (hai un passaggio in più, c'è chi lo
preferisce, chi no - io no)
- git permette di riscrivere la storia liberamente, hg non proprio se
non in casi eccezionali
- il pull si comporta differentemente quando usi i branch, come lo usa
hg mi sembra molto più naturale (i changeset sono associati ad un branch
specifico, se vuoi fare un merge lo devi fare esplicitamente)
- settare un'interfaccia web è roba di pochi secondi con hg, con git mi
sono rotto dopo che non ho trovato nulla di utile/semplice, ma magari
adesso la situazione è migliorata
- i comandi hg sono simili a quelli cvs/svn, indi il passaggio è quasi
indolore
- all'epoca hg era multipiattaforma, git no
- i repo git tendono ad ingrossarsi, e quindi sarebbe il caso di
eseguire una garbage collection degli oggetti non più raggiungibili
(prima era da fare a mano, adesso mi sembra sia fatta quasi in automatico)
- facilità a sminchiarsi i dati, costringento a fare un clean up del
progetto (o altrimenti: perché 3 progetti che seguo su git e di cui
faccio solo ed esclusivamente il pull - niente altro! - ogni tanto mi
rifiuta il pull perché gli oggetti non corrispondono?)

 (come vi proteggete dal furto di codice?)
Un sistema di revisione non impedisce assolutamente nulla.
È altro su cui devi fare affidamento.
Cosa sinceramente non so.

 necessariamente identici.
ok, bzr invece ha un id identico per tutti i repo
http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-hg-users.html#revisions
peccato che:
    * The downside is that the common practice (for hg/git users) of
“merge upstream into feature branch then push upstream” will make the
upstream a mirror of your feature branch, changing the upstream revision
numbers and most likely annoying other contributors.
The solution is simple: do not push from a feature branch to upstream.
As explained earlier, the right process in Bazaar is to keep a trunk
branch that mirrors upstream and merge your feature branch into that
instead.
il che è un remare contro secondo me, invece di aiutarmi mi introduce un
altro paletto cui fare attenzione...

 mini-commit.
Non nel nostro caso.
Non siamo una macchina sforna software.
I nostri programmatori non fanno programmazione
8 ore al giorno tutti i giorni.
Abbiamo da seguire dei progetti, alcuni anche
molto grossi, ma non siamo la Microsoft, spesso
i programmatori devono fare formazione ai commerciali
su software appena realizzato o assistenze telefoniche.
Non avremo 100 commit al giorno, almeno non credo...

 Credo anche io.
Tu come lavori? Ed in quanti siete?
Come gestisci il repository?

 Ni. Il pull lo farà solamente quando deve fare il push.
Vero, giusto, non ci avevo pensato.

 Hanno senso eccome. Ad esempio creare in automatico una directory uploads.
Precisamente, e guardacaso, il 99% dei nostri progetti è via web,
per cui cms, gestionali vari e tutti (ma proprio tutti) hanno una o
più directory di upload che inizialmente sono vuote.

 altro paletto cui fare attenzione...
Vale a dire, se ho ben capito:
scarico l'upstream in locale
creo un feature branch.
NON pusho quel feature branch ma lo unisco al mio repository locale
carico in upstream la mia copia locale unita al feature branch.
se è così, mi sembra lineare come cosa...
a me son tutti quei dannati branch che ti fan creare (o ti suggeriscono
di creare) i vari dvcs. Per la mi seria, mi fanno fare un casino
mentale assurdo. Scarichi da una parte, cloni, lavori dall'altra,
unisci in locale. Mah.

 fai i merge diventa ancora più complicato.
A me interesserebbe avere una history 'annidata' fatta
in questo modo:
http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html#hierarchical-history-is-good
ma sono 3 giorni che smanetto e non ci cavo le zampe.
Una history così strutturata sarebbe comoda, perchè ti permetterebbe
di identificare, ad occhio, chi ha fatto cosa e di poter identificare,
sempre ad occhio, un eventuale commit verso il quale ripiegare se
dovesse crollare tutta la baracca.
Però:
- i commit mainline non avrebbero ragione di esistere, o sbaglio?
Se si lavora a feature-branch, come è possibile che si vada a
committare direttamente in mainline come se fossimo su SVN?
Lavorare a featurebranch in quel modo comporterebbe una history
sempre ad albero, dove gli unici commit mainline sarebbero quelli
dei merge fatti per sincronizzare i singoli feature branch.
In pratica:
|
+\
| +--feature2
+/
+\
| +--feature1
+/
|
Ma ha senso questa struttura?
A me questa struttura distribuita sembra utile solo
nel caso gli sviluppatori non potessero lavorare sempre
online in un repository condiviso come ad esempio gli
sviluppatori dei vari progetti open-source. Sono sparsi
per il mondo, farli lavorare tutti in maniera distribuita,
in un singolo server, quando ci sono 15.000 sviluppatori
comporterebbe un gran macello logistico. Ci sarà sempre
qualche persona che pusha, dato il numero di persone
coinvolte, e di conseguenza ci sarà sempre qualcuno dietro
ad pullare la propria base dati.
Se si lavora dentro una software house con pochi sviluppatori
mi pare che il modello centralizzato abbia più senso.
Lavori solo e soltanto se va il server centrale, tanto se non
va non riusciresti a lavorare nemmeno in maniera distribuita
(vuoi perchè non ti va il terminale stupido, vuoi perchè non
puoi più autenticare sul dominio, bla bla bla)
Distribuire il lavoro in 50 centimetri, all'interno dello stesso
gruppo di scrivanie, mi pare 'na stronzata. Non è un lavoro
distribuito ma è "sparso" qua e la.

 writes:

Io da solo programmando 2-3 ore 15/20 commit li faccio tranquillamente.
Dipende tutto da quanto sono veramente atomici i commit, altri magari
preferiscono accorpare più cambiamenti ma per avere un messaggio di
commit sensato secondo me devono essere più atomici possibile.
Come dicono anche altri cerchi di fare i conti senza l'oste, capisco che
gli informatici possano mancare di simpatia e socievolezza, ma caspita
sono loro poi che dovranno usarlo tutti i giorni...

 sono loro poi che dovranno usarlo tutti i giorni...
Io non ho mai visto far fare la policy aziendale agli ultimi
arrivati. Mai.
I programmatori hanno un gran turnover qui, se dessimo retta
a loro anche per la policy aziendale saremmo paralizzati.
Fortunatamente io sono abbastanza stabile (è 5-6 anni che son
qua) e su certe cose mi danno carta bianca, tra cui questa.
Visto che dovrò usarlo anche io, prima voglio scremare, poi
giustamente, si propone. Ma una scrematura inziale ci vuole.
Andare a chiedere un parere tra:
cvs
svn
bazaar
git
mercurial
(l'altro di cui non ricordo il nome)
significherebbe non concludere nulla.
Comunque sia, credo che optero però mercurial?
Perchè?
1) è simile a git, ed in mezzora si impara a fare
l'ordinaria amministrazione (bazaar è ormai una
settimana che smanetto e non ho capito un cazzo di niente.
chiama tutto branch. un branchè  dentro un repository, un
repository è un insieme di branch....)
2) ha la numerazione sequenziale.
3) il fatto di poter non poter cambiare la history per me
è meglio. Bazaar la fa sovrascrivere in certi casi, mercurial
mai. Tra l'altro, mi pare di capire che se si annulla un commit
o un merge, viene automaticamente creato un commit che contiene
l'opposto del precedente. In pratica la history avanza sempre.
In bazaar sarebbe eliminato proprio l'intero commit, anche
dallo storico.
Domani provo, ma sono quasi certo. Leggevo un po di documenti
ed il modo di lavorare, come han scritto altri, è veramente
naturale. ti viene spontaneo eseguire certi comandi perchè sai
già cosa faranno. Con bazaar questo non mi è mai capitato, anzi,
come ho scritto sopra, non ho capito nemmeno come ragiona.

 non gestisce proprio il revision number.
Per quello che vuoi fare non ti serve, non riesco a capire perché lo
vuoi a tutti i costi. È un'inutile complicazione. Non stai usando svn.

 distribuito ma è "sparso" qua e la.
Allora usa svn e non farti paranoie.

 l'opposto del precedente. In pratica la history avanza sempre.
Dipende:
hg rollback elimina completamente l'ultimo commit, comodo se hai
sbagliato qualcosa e non hai ancora condiviso il cambiamento
hg strip fa lo stesso con più commit, e analogo a quello di cui sopra
altrimenti hg update <rev-valida> && hg ci -m "revert allo stato
decente" e ti tiene traccia di tutto
http://gpiancastelli.altervista.org/hgbook-it/
http://hgbook.red-bean.com/

 significherebbe non concludere nulla.
Certo, se i nuovi arrivati non sanno fare un tubo hai ragione, ma se ti
arriva uno sviluppatore con 10 anni di esperienza faresti bene ad
ascoltarlo.
Chiedere un parere non significa dar retta ad ogni modo..
E non intendevo nemmeno chiedere un parere su cosa usare, ma solo come
usarlo eventualmente, ma insomma non sono affari miei.

 
http://hgbook.red-bean.com/
Questo manuale è semplicemente fantastico.
Solitamente leggo i manuali inglesi, ma quello Italiano
è davvero fatto bene ed è molto scorrevole come lettura,
tant'è che uso quello come riferimento e lo darò da
leggere agli sviluppatori. E' impossibile non capirlo,
a differenza di bazaar che mischia i termini anche dentro
la stessa pagina della sua documentazion (working-dir,
working-tree, bla bla bla)

 sapere l'hash...)
Ma perchè devo fare un repository per ogni sviluppatore?
Proprio non ne vedo i vantaggi.
Lavoriamo tutti nella stessa scrivania, distribuire così tanto per
me è solo una complicazione. Non stiamo sviluppando il kernel dove
ci sono altri 100.000 sviluppatori in giro per il mondo.
Siamo in 5 e tutti e 5 siamo nello stesso posto, a pochi centimetri
di distanza.
Mi sembra più lineare ed intuitivo lavorare in maniera centralizzata
o semi-centralizzata con i commit locali.
Ogni sviluppatore clona il progetto in locale, lavora, fa i suoi bei
commit e poi pusha sul server, nel ramo "trunk".
La stessa cosa faranno tutti gli altri.
Quando la relese è pronta, si fa un branch ad-hoc lasciando sempre
aperto il trunk.
La semplicità nel creare i branch è notevole, e saranno utilizzati per
sviluppare feature 'particolari' o corpose.
In caso di necessità lo sviluppatore si crea il suo branch, lo modifca
e poi fa il merge nella sua copia locale del trunk. Da li poi pusha.

 Scuse (sinceramente).
Ma anche no.
Se il server centrale è fermo, qui da noi non accedi ai
computer, non ti ritrovi il profilo del windows, non ti
ritrovi alcuna applicazione installata dato che sono tutte
via rete (quelle degli sviluppatori) e non accedi ad alcun
file di progetto.
Non sono scuse, non si riesce a lavorare proprio.

 nel tip del repository più alto.
Rimango convinto che non sia la strada corretta, cmq non è un problema
enorme se usi i tag. Al massimo puoi sempre cambiare rotta senza grossi
problemi.

 Non sono scuse, non si riesce a lavorare proprio.
ok, allora avete problemi molto più grossi :D
sono io che sono abituato troppo bene ;)

 aperto il trunk.
Sai che hai appena descritto un sistema centralizzato con un dcvs?
Sopra hai detto che è impossibile ;)

 Ottimo :D
Da quello che dice più che altro in "brain sharing", un cervello per n
tastiere che scrivono.
Quoto completamente il resto, e vorrei aggiungere che secondo me se avessi
davvero provato a mettere in piedi un mini progettino con revision
control avresti capito che la maggior parte di questi tuoi problemi non
esistono o si risolvono semplicemente facendo le cose come si dovrebbero
fare ;)

 Sopra hai detto che è impossibile ;)
No, non è centralizzato. E' semi centralizzato.
Un sistema centralizzato fa il push in automatico ad ogni commit.
Tant'è, che bazaar (ad esempio) se lo imposti in modalità centralizzata
quando fai il commit ti pusha da solo.
Per questo dicevo che sarebbe impossibile gestire tanti commit in un
sistema centralizzato con molte persone. Ci sarà sempre qualche d'uno
che ha appena committato e te devi star dietro a fare il pull ogni 2x3.

 sono io che sono abituato troppo bene ;)
Non li chiamerei problemi.
Il server centrale è ridondato.
Volevo solo farti capire che se dovesse fermarsi il
serverone, non si fa più nulla. DVCS o no, non cambierebbe
niente poter lavorare in locale. Tutto il software è sul server.

 fare ;)
E come "si dovrebbero fare" ? Sto cercando di capire proprio questo.
A me un workflow tipo:
hg clone
<lavoro>
commit
<lavoro>
commit
hg pull
andrebbe benissimo, ma in nessuna documentazione di nessun dvcs ho letto
che è un metodo consigliabile in quanto sarebbe una forzatura nel voler
utilizzare un dvcs in modalità simile a svn (simile perchè i commit sono
in locale e non in remoto, per cui non bisogna sincronizzare nulla tra
un commit e l'altro, ma solo con il push)

 writes:

Visto che i tuoi geni probabilmente non capiranno mai cos'è un branch
uno workflow del genere secondo me va benissimo (tra parentesi è come
faccio io, ma lavoro di solito da solo o al massimo in 3).
Non è consigliato perché non lo sfrutti a dovere, ma chettefrega, in
futuro potrai migliorare.
La cosa più stupida è pensare di dover per forza trovare il workflow
definitivo ancora prima di iniziare, stai perdendo solo tempo.
Intanto comincia dal modo più stupido poi vedi come va.

 Visto che i tuoi geni probabilmente non capiranno mai cos'è un branch
E perchè mai?

 E perchè mai?
Me lo dice la palla di cristallo...
Comunque ho trovato questo bell'articolino su git, magari può servire a
chiarire le idee in generale
http://eagain.net/articles/git-for-computer-scientists/

 
http://eagain.net/articles/git-for-computer-scientists/
Me lo leggo con calma questa sera...
Grazie.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.