Newsgroup: it.comp.os.linux.sys
Titolo: Controllo Versione ed interfacce web

Devo selezionare un sistema di controllo versione
che sia relativamente semplice da usare e comprendere
e che abbia una interfaccia via web in PHP.
Avrei visto git, che mi sembra abbastanza semplice da usare
e come interfaccia InDefero mi sembra valida (ï¿œ un clone di
google code, che sarebbe perfetto per il mio scopo, ma non
posso/voglio usare software 'esterno'). L'interfaccia mi serve
giusto per salvare commenti, gestire eventuali bug e navigare
tra le varie versione ed i vari branch visualizzando chi ha
modificato cosa.
Il 99.9999999999(periodico)% del codice da gestire tramite
controllo versione sarï¿œ PHP/HTML/JS/CSS. Nient'altro.
L'IDE utilizzato per lo sviluppo del codice sarï¿œ NetBeans che
se ha il supporto a svn, csv, mercurial e git come plugin.
Chi dovrï¿œ utilizzare il codice non sa nulla di linux e non avrï¿œ
alcuna shell da cui invocare i comandi di clone, commit e tutto
il resto, per cui mi serve obbligatoriamente un sistema di controllo
versione gestibile interamente da NetBeans (o altri IDE per windows)
e da frontend in PHP.
Cosa consigliate? Git puï¿œ andare?
Diciamo pure che non conosco benissimo il modo corretto di lavorare
con tali sistemi (devo imparare), ma pensavo di fare cosï¿œ (ditemi
se sbaglio):
1) io creo il progetto con git init e faccio il commit di un progetto
vuoto.
2) creo un branch experimental
3) gli sviluppatori fanno il checkout di experimental (che inizialmente
sarï¿œ vuoto)
4) fanno quello che devono fare con il codice
5) fanno il commit di experimental con "git commit -a" che aggiunge 
eventuali nuovi file al branch.
6) io faccio il merge di experimental nel master.
In questo modo, le modifiche si fanno su experimental, si testano, e se
tutto funziona si fa il merge con il master.
Domandina: supponiamo che ci siano due sviluppatori.
Sviluppatore 1 cancella la funzione "prova()".
Sviluppatore 2, parallelamente, crea un pezzo di codice che richiede
la funzione prova, che perï¿œ ï¿œ stata eliminata da sviluppatore1.
Ovviamente non funzionerï¿œ un tubo.
Esiste un modo per semplificare anche questa gestione?
In maniera analoga, i due sviluppatori potrebbero creare, per vie
parallele, la stessa funzione con un evidente conflitto di nomi e/o
fare la stessa modifica di codice. Anche in questo caso, esiste un
modo per tutelarsi? Non sempre ï¿œ possibile far "parlare" i due
sviluppatori, i quali potrebbero essere in due continenti differenti
con 12 ore di fuso orario.
Per il momento grazie e buon anno.

 orario.
Nessun VCS puo` risolvere questi problemi.
Li risolvi solo in due modi:
- parlando
- progettando
La programmazione OOP (e derivati, come lo unit testing) aiuta molto da 
questo punto di vista, perche` assegni una classe o un namespace a ogni 
utente, e lui deve occuparsi solo di quello, e non deve toccare la roba 
degli altri.
Le API, una volta definite e pubblicate, non andrebbero modificate se non 
dopo riunione e riprogettazione delle stesse, e solitamente richiedono un 
branch distinto del software, finche` non sara` stato tutto 
rifattorizzato e testato.
Bye.

 degli altri.
Vero, ma non sempre è possibile convertire interi progetti ad oggetti.
Per i progetti più vecchi, fatti proceduralmente, servirebbero i 
namespace o cose simili.
O al massimo incapsulare le funzioni dentro una classe.
Soluzione di merda, ma almeno ti permette di evitare casini con le
doppie dichiarazioni. Se lavorano 2-3 programmatori non avresti
alcun problema a parlare, ma se i programmatori diventano 100 o 1000
il "parlare" non è sempre fattibile, senza una buona progettazione
iniziale, che è appunto quella che sto cercando di fare.
Rischi di perdere più tempo a "parlare" che a fare codice.
A parte questo, hai qualche VCS da suggerire? Esperienze con Git?
L'unica cosa che non mi piace è il suo modo di gestire (o meglio, non
gestire) le release. SVN codifica sequenzialmente un intero, Git fa
un hash SHA, per cui non si avrebbe una gestione delle versioni in
formato umanamente comprensibile.
-- 
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.

 A parte questo, hai qualche VCS da suggerire? Esperienze con Git?
No. Io continuo a usare CVS e SVN, che per piccoli gruppi (4-5 persone 
come siamo ora) vanno piu` che bene. :)
Bye.

 come siamo ora) vanno piu` che bene. :)
Leggevo alcuni commenti di Linus riguardo a CVS/SVN.
In poche parole vengono identificati come "il male", allora visto
che devo partire da zero, che non ho idea di come funzionino tali
sistemi e che non ho alcun pregiudizio, tanto vale partire con uno
che non sia visto come "il male". :)
Usi qualche pannellino via Web? Quello che ho indicato nelle mail
precedenti sembra validissimo, peccato che non faccia vedere, per
ciascun file, tutte le revisioni possibili. Ti fa vedere solo l'attuale
versione, per vedere le precedenti devi aprire ogni singolo changelog.
In pratica, Google Code è più intuitivo, ma non è downloadabile.


 Cosa consigliate? Git può andare?
Personalmente ti consiglio Mercurial in quanto:
 - E` un DVCS come Git;
 - E` abbastanza semplice da usare;
 - Ha un frontend web (egli stesso e trac con plugin);
 - Ha un frontend Windows (TortoiseHG).
Lo uso tramite linea di comando per progetti personali (a lavoro usiamo
SVN), e non mi trovo male
Enrico

  - Ha un frontend web (egli stesso e trac con plugin);
Si, ma trac non è in PHP.
Preferirei un frontend web in PHP, perchè in caso di necessità
posso modificare il codice.
(qualcuno mi sa dire, con git, come visualizzare tutte i commit
disponibili per ciascun file? Ad esempio, se io avessi un file
di nome "ciccio.php", come posso vedere in quali commit è stato
modificato?)


 modificato?)
Mi rispondo da solo:
git log "ciccio.php"


 In pratica, Google Code è più intuitivo, ma non è downloadabile.
Mm google code credo non c'entri nulla con git, usavano subversion e mi
pare da poco mercurial.
Comunque sicuramente i DCVS sono in gran passo a avanti rispetto a
CVS/SVN, ma dipende anche dal livello dei tuoi programmatori, se dici
che non sanno neanche cos'è una shell non credo che sfrutteranno nemmeno
1/100 delle features di git...
Una bellissima interfaccia per git piuttosto sarebbe quella di github
https://github.com/
che non è scritta con quel catrame di php ma in ruby per fortuna ;)

 posso modificare il codice.
E` lo stesso discorso che mi fecero in ufficio quando implementati Trac
per la gestione dei ticket, e ti rispondo alla stessa maniera: e` un
discorso ad minchiam. Considerando che Trac e` totalmente customizzabile
via CSS (per quanto riguarda l'aspetto grafico), via file di
configurazione (per quanto riguarda il flusso e la gestione dei ticket)
e via plugin (per quanto riguarda le funzionalita`), gli unici motivi
per cui ho bisogno di mettere mano al codice sono:
 - L'applicazione manca di alcune funzionalita`.
 - L'applicazione ha dei bug.
 - L'applicazione L'applicazione segue un flusso ceh non mi piace.
Di questi tre motivi, solo il secondo ha senso in quanto significa che
ho interesse a mantenere "viva" l'applicazione, e quindi voglio
diventare un membro attivo della comunita` che vi gira attorno. Di
contro, nonostante ne abbia la possibilita`, non ho mai avuto bisogno
di mettere mano al codice di Trac in quanto non mi sono mai imbattuto
in bug o in funzionalita` mancanti che non si potessero risolvere
aggiornando il software oppure con l'ausilio di plugin sviluppati da
terzi. Poi ovviamente fai come vuoi, ma cio` non toglie che, secondo me,
la motivazione da te presentata non regge
Enrico

 che non è scritta con quel catrame di php ma in ruby per fortuna ;)
Si ma.... da dove si scarica?

 la motivazione da te presentata non regge
Non proprio.
L'applicazione che ho indicato poco fa è fatta in PHP, ma ha
una grossa mancanza: non visualizza le revisioni di ciascun file.
E' una modifica che mi devo fare da solo.
Inoltre, preferirei integrare il tutto nel nostro gestionale/crm
interno, ed abbiamo solo sviluppatori PHP. Un programma in python,
ruby, quel che vuoi, sarebbe una entità a se stante e non integrabile
con i nostri applicativi.

 con i nostri applicativi.
In effetti l'interfaccia che usa github non so se è scaricabile, ma un
tempo mi sembrava di averne visto il codice sorgente, un miraggio?
Comunque se gli sviluppatori sono in giro per il mondo converrebbe
magari pagare un hosting proprio su github, io ho usato solo la versione
free ma è veramente spettacolare a mio parere.
Per quanto riguarda il php non saprei, è meglio qualcosa che funziona
veramente bene e sia configurabile rispetto a un colabrodo in php a cui
ci metti qualche pezza tu.
Ti vai poi veramente a mettere nei pasticci nella gestione degli
aggiornamenti, non so se ne vale la pena.
L'integrazione si può avere comunque in mille modi, non è di certo
necessario che sia scritto nello stesso linguaggio.

 necessario che sia scritto nello stesso linguaggio.
Si, ma io conosco PHP, come faccio a sviluppare codice in ruby, ad esempio?

 Usi qualche pannellino via Web?
No. Solo l'integrazione in eclipse/netbeans e programmini appositi per 
Windows.
Bye.

 Bye.
Con git ho gitweb, ma non lo uso praticamente mai. Qgit2 e Gitk come
client grafici, tig come client testuale con n-curses, riga di comando
per tutte le operazioni.
PSK

  
Lo credevo anche io, ma Mercurial, anche per sviluppatori singoli, è 
molto meglio di Subversion.
E pensa che io non uso nemmeno molto i branch; è proprio la UI di 
Mercurial ad essere fatta meglio; per non parlare della interfaccia web 
che hai a disposizione.
Ciao  Manlio

 membri e uno distribuito necessita di coordinamento.
Nel mio caso, è più facile coordinare i membri, piuttosto che garantirne
la comunicazione tra di loro.
Per cui, punterò ad un sistema distribuito, dove ogni membro fa quel
cavolo che vuole nella sua copia locale di codice, fa il commit del
suo ramo e poi io coordino il merge con il ramo principale.
Però, come ho scritto, non sono molto pratico di questi arnesi e non
conosco il modo di lavorare corretto.
Supponiamo di avere i due sviluppatori (dev1 e dev2) ed il boss che
coordina lo sviluppo (io).
Il progetto si chiama "ciccio".
Il boss crea il progetto ciccio.
Il boss crea tre rami: stable, testing, experimental sulla falsariga di
debian per cui tutti sapete cosa fanno i singoli rami.
dev1 deve fare delle modifiche al codice aggiungendo nuove features.
Fa quindi il checkout di experimental e se lo porta sul suo computer.
Fa tutte le modifiche del caso. Terminate, fa il commit di experimental.
Parallelamente, dev2 deve fare altre modifiche, quindi anche lui farà il
checkout di experimental.
Si arriverà ad un punto in cui l'experimental di dev1 e dev2 
differiscono tra loro a causa delle modifiche apportate da ciascun dev.
Teoricamente, se le modifiche non fanno a cazzotti tra loro, sarà compito
del VCS fare il merge dei due sviluppatori nel singolo ramo 
experimental, applicando le patch per ciascun dev. Corretto?
Se invece il codice collide con altre modifiche apportate da un altro
dev, sarà compito dei due dev dialogare e trovare una soluzione che
vada bene ad entrambi. Qualcosa tipo:
"Hey, ho bisogno di fare questa cosa, ma con le tue ultime modifiche non
è possibile. Puoi ristrutturare il codice tenendo conto che io devo
fare anche questo e quest'altro?"
Nel caso di OOP, sarebbe più semplice in quando dev1 lavorerebbe sulla
classe1, mentre dev2 lavorerebbe sulla classe2 e difficilmente le
modifiche fatte a classe2 vanno a collidere con la classe1.
(salvo errori di compilazione che sono facilmente identificabili e
risolvibili da un singolo dev. Se classe1 spacca il codice, dev1 lo
può risolvere senza alcun intervento di dev2).
In caso di programmazione procedurale, è più complesso, perchè la
funzione fatta da dev1 potrebbe collidere con la funzione fatta da dev2
ed in tal caso, bisogna rivedere un po tutto (è consigliabile tenere
la funzione di dev1 o quella di dev2? Se la vedranno tra loro i due dev)
Supponiamo di dover correggere un piccolo bug presente nel ramo stable.
Lo si può fare direttamente sul ramo stable. faccio il checkout,
modifico il codice e faccio il commit.
Ma così facendo, il ramo testing ed experimental saranno sempre soggetti
al bug, dato che esso non è stato fixato su tali rami.
Come fare? Devo riapplicare la modifica manualmente su ciascun ramo?
I rami testing ed experimental, ma sopratutto quest'ultimo, possono
differire di molto dal ramo stable, per cui non è detto che lo stesso
codice possa essere applicato as-is agli altri rami.
Diciamo pure che gestire il passaggio verso l'alto, ovvero da 
experimental verso la stable è molto più facile che fare l'inverso.
Da experimental verso la stable, man mano che si fixano i bug, è il
ramo stesso a diventare sempre più "stable", per cui ad un certo punto
gli si cambia il nome e si parte con un nuovo experimental.
Ma l'inverso è problematico, un bug non può essere fixato solo nella
experimental, perchè potrebbero passare mesi di sviluppo prima che tale
branch vada in stable, e dallo stable non sempre si può tornare ad una
experimental senza dover magari rifare ore e ore di sviluppo.
Cosa suggerite?

 Cosa suggerite?
Certamente di fare molte prove prima di iniziare ad utilizzare uno
strumento.
Un VCS è comunque uno strumento complesso e molto versatile.
Io ho scritto secondo la mia esperienza con git (e non pretendo che sia
il modo migliore in assoluto per lavorare).
Altri VCS possono essere più efficienti con metodi di lavoro leggermente
differenti.
Imparare ad utilizzare un VCS può essere complesso.
Imparare ad utilizzarlo bene, decisamente più complesso e delicato.
Imparare ad impostare un sistema VCS richiede di conoscere bene molte cose.
Quindi non ti scoraggiare se ti sembra che sia complicato. Se ti sembra
troppo complicato, chiediti se non sei tu che stai affrontando il
problema in un modo poco ortodosso.
Spero di non aver creato confusione.
PSK


Questa mi sembra una pessima cosa, e nessun VCVS può aiutarti quando
dovrai cercare di mettere insieme schifezze di vario tipo e origine.
Per quanto caprini e sociopatici che possano essere i tuoi
sviluppatori, saranno in grado di reggere qualche breve riunione e
leggere/mandare mail, no?
Non ha assolutamente senso che sia tu a fare il merge, piuttosto
bisogna scrivere dei test di regressione e usare unit testing a più
non posso ed essere certi che qualsiasi commit non vada ad invalidare
il funzionamento.
Altrimenti semplicemente le modifiche non vanno accettate e non
entrano nel ramo principale.
Se ogni sviluppatore si mette a fare le cose per i ca*** suoi e magari
cambia n-mila righe alla volta diventerai pazzo molto presto.
Per quanto riguarda l'interfaccia grafica poi non ne vedo nemmeno
questa gran necessità, anche io uso tig/emacs con magit e ogni tanto
apro git gui e non mi manca nulla, anzi.

 Nessuno nasce imparato :-)
Quoto solo questa riga, perchè il resto del tuo
discorso mi ha mandato in crisi. Troppi termini
strani :D
Esiste un libro/ebook/howto che illustra il modo
corretto (o uno dei tanti modi corretti) di operare
mediante un sistema di controllo versione?
Oltre alle innumerevoli prove da fare, ci sarà pure
un concetto di fondo da seguire per evitare di ritrovarsi
con il culo davanti alle pedate no? Ecco, sto cercando
di trovare quel concetto. Poi sulla base di esso potrò
fare le dovute prove, ma senza avere almeno una base
mi ritroverei a provare letteralmente alla pene di segugio.

 writes:

Ci sono parecchi testi e mi pare ci fosse un libro della O'Reilly su git
uscito non molto tempo fa.
Comunque fai parecchie prove di disastri possibili e tentativi di
recupero, installa qualche frontend ma impara anche a usarlo dalla linea
di comando (a volte l'unico modo per risolvere i problemi).
Per il resto Keep It Simple e cerca di far capire come funziona anche
ai programmatori, altrimenti se poi loro non sono in grado di usarlo
decentemente sei punto e a capo.

 decentemente sei punto e a capo.
Ora devo vedere come si comportano gli strumenti di sviluppo come
netbeans, pspad e zend.
Da quel che ho capito io devo creare un repository sul server centrale,
dal quale ogni sviluppatore fa il proprio checkout e di conseguenza
lavora in locale.
Il massimo sarebbe poter gestire, sempre tramite l'IDE per lo sviluppo,
il commit in un repository dedicato allo sviluppatore, in modo che sia
possibile testare le modifiche direttamente su un server clone di quello
in produzione, senza dover fare il commit sul repository principale.
Anche perchè se creassi dei tag o dei branch per ciascun sviluppatore,
come dico ad apache di leggere un dato branch, visto che git cambia
il contenuto dei file in base al branch attivo in quel momento?

 il contenuto dei file in base al branch attivo in quel momento?
Non so come funzioni apache in questi casi, comunque mi sembra
inutilmente complicato mettere in piedi dei server clone.
In fondo lo sviluppatore può fare tutti i test che vuole in locale, poi
quando è sicuro di non aver fatto cazzate grosse fa il push degli ultimi
commit sul server centrale.
Se per caso ha comunque fatto delle cazzate non è comunque difficile
tornare "indietro nel tempo".

 commit sul server centrale.
Nel caso di progetti complessi, fare i test in locale significa
appunto mettere in piedi un server clone. Per fare test veritieri,
dovresti quantomeno avere la stessa configurazione del server reale,
e se gli sviluppatori fossero 15, cosa fai, installi 15 cloni su
ciascun computer?
Si fa molto prima a fare un singolo server clone di quello in
produzione e far caricare tutti li sopra. Il più è capire come.

 Se il titolo non mente non è solo un manuale per git (
amazon.co.uk
)
Parla solo di git... E' grossomodo lo stesso manuale presente
sul sito ufficiale di git, gli argomenti son gli stessi.
http://oreilly.com/catalog/9780596520137
http://tinyurl.com/yjvv2fn

 Se il titolo non mente non è solo un manuale per git (
amazon.co.uk
)
Questo libro è davvero ben fatto.
Parla solo di git, ma spiega molto bene come usarlo.
Ora non si può più dire che git manca di documentazione, questo
libro racconta tutto. Magari non nei minimi particolari, ma per chi
parte da zero è veramente una bibbia che ti permette di capire
perfettamente come funziona tutto il sistema.

 Spero di non aver creato confusione.
A dire il vero ne hai creata molta :)
Ho fatto ulteriori prove.
Lavorare con un singolo sviluppatore è
relativamente semplice, ed anche molto comodo
perchè ti permette di saltare da una versione
all'altra in tranquillità e rapidità.
Stando ad un libro, vien suggerito di fare branch
distinti per ogni versione. A differenza di SVN dove
gestire branch potrebbe essere complesso, con git è
veramente una cavolata per cui vien consigliato di fare
branch anche per sciocchezze.
Ad esempio, si consiglia di partire da una base dati
master, ovvero la default.
Da li, si creano dei branch distinti:
- stable
- testing
- dev
Si lavora solo sulla dev.
L'utente Mario farà il suo branch a partire dalla dev:
dev/Mario
L'utente Franco farà uguale:
dev/Franco
così facendo, i due sviluppatori lavorano ciascuno per i
fatti suoi partendo da una base comune, la dev.
Al termine delle modifiche, Mario committa e fa il merge
su dev, taggando "1.0.1-dev"
La stessa cosa la farà Franco: commit+merge su dev taggando
la nuova dev (ovvero il nuovo commit generato dal merge) in "1.0.2-dev"
Così facendo la dev avanzerà sempre, e ci sarà sempre un tag indicante
la versione. Se vien fuori un bordello, si può sempre fare il clone
della 1.0.1-dev, ad esempio, eliminando le modifiche di Franco, il quale
potrà riprovare il commit+merge in un secondo tempo.
Il branch "dev" avrà l'HEAD puntata sempre sull'ultima versione
disponibile, e per comodità ci saranno anche i tag sulle varie
"milestone" o cambi di versione, ovvero i singoli merge tra gli sviluppi
dei developers ed il ramo dev stesso.
Se tutto funziona, dopo un po di tempo, uno dei due sviluppatori farà
il merge della dev (ovvero l'ultima versione) alla testing, e taggherà
anche questa operazione.
Su testing ci sarà solo bugfix e nessuna nuova features.
Se la test sembra stabile, io farò il merge in stable, e taggherò.
Se dovesse arrivare uno sviluppatore Paolo, dovrebbe bastare creare
un nuovo branch di nome dev/Paolo a partire dalla ultima dev e
ricominciare tutto il giro.
Dovrebbe venir fuori una cosa simile:
dev/Mario  dev/Franco
      \             \
------1.0.1--------1.0.2----+--------------------dev
                              \
------------------------------1.0.3---+----------testing
                                        \
-----------------------------------------1.1.0---stable

 produzione e far caricare tutti li sopra. Il più è capire come.
Sì in effetti hai ragione, sono abituato a lavorare in locale quindi non
ci penso...
Comunque a questo punto allora ti converrebbe farli lavorare in qualche
modo direttamente sul server clone.
Con git conviene fare molti micro-commit, uno per ogni modifica, se ad
ogni commit i tuoi sviluppatori devono fare due passaggi diventano pigri
e cominciano a fare commit più corposi, almeno io farei così...

 e cominciano a fare commit più corposi, almeno io farei così...
Infatti, il massimo sarebbe poter fare commit/push direttamente da
dentro l'IDE (NetBeans per ora) con il push su un server clone.
Così ad ogni commit si ritrovano già il clone sincronizzato e
controllano direttamente.
Vorrei infatti evitare di far lavorare in locale, fare il commit e dover
caricare tutto su un server clone, come in pratica accade adesso.
Mi sa che solo bazaar faccia una cosa simile.....

 controllano direttamente.
Che problema c'è nel mettere un hook nel repository centrale che ad ogni
push lui fa automaticamente un push sul server di test in modo che allo
sviluppatore basti fare un solo push?
per mercurial basta mettere in $PROJECT/.hg/hgrc una cosa del tipo
[paths]
server-clone = ssh://dove/sta/il/server
[hooks]
incoming = hg push server-clone

 sviluppatore basti fare un solo push?
Interessante, non ci avevo pensato.
Però, così facendo lo sviluppatore deve fare sempre
il push del progetto sul server vero.
Sono in attesa che mi arrivino due libri su git ordinati
da amazon e ne approfitto per fare una domanda:
il push, copia tutto il progetto locale sul server oppure
copia solo il branch in uso in quel momento?
Inoltre, la copia remota mi vien sovrascritta con quella
dello sviluppatore?

 dello sviluppatore?
Ti rispondo per mercurial: fino a che non dai un hg update non aggiorna
nulla (ovvio, se lo metti nell'hook lo puoi abilitare di default)
E lo stesso vale quando fai il pull: git pull scarica e aggiorna, hg
pull scarica e basta, per aggiornare o usi il flag -u o dai un hg update
(mi sembra si possa fare anche con git, se non sbaglio git fetch && git
checkout <quellocheè> - credo ma non sono sicuro).

 branch voluto. Git copia solo i branch che gli dici di copiare.
Credo di essermi espresso male.
Supponiamo di avere un repo su 
http://pippo.it
io faccio
git clone 
http://pippo.it
lui scarica tutto il repository, compreso tutti i branch.
poi do:
git branch cicciopasticcio
git checkout cicciopasticcio
creo un nuovo branch, e lo imposto come predefinito.
Faccio le modifiche.
Faccio il commit
Faccio il push.
Che succede? Git fa il push solo del branch o di tutto
il progetto? Supponendo di aver fatto un casino e di
aver modificato anche il branch master, git mi carica
anche quello?
In pratica io vorrei fare il clone dal server principale,
ed il push sul server di backup.
Con il tuo sistema, posso fare un hook che mi carica sul
server di backup i file, ma per invocarlo devo fare comunque
il push, ed in tal caso il push lo farebbe sul server principale.
Non va bene.
In alternativa, posso fare il merge di due progetti cloni?
Esempio (lavoro sul server di backup)
git clone 
http://servermaster.it/progetto.git
(lavoro sul pc dello sviluppatore)
git clone 
http://serverbackup.it/progetto.git
git push (in teoria, carica tutto sul server di backup, dato
che il clone arriva dal di li).
Ora, volendo sincronizzare il backup con il master, posso
fare qualche cosa di sto tipo (sul master):
git merge 
http://serverbackup.it/progetto.git
?
Così facendo potrei creare il progetto sul master, clonarlo
sul backup e far fare agli sviluppatori  vari clone/checkout/push
sul backup.
Quando tutto funziona, faccio il merge del branch dev presente sul
server di backup, con il branch stable presente sul master.

 In alternativa, posso fare il merge di due progetti cloni?
[snip]
Direi che si, visto che è il concetto base di un DCVS. E' il suo
workflow naturale (qualunque DCVS)

 default-push = serber-backup
ESATTO!
Quello che voglio fare.
Voglio avere in sola lettura per gli sviluppatori il server master.
Mentre in lettura scrittura il server backup.
Il pull si fa sempre dal master, che avrà sempre la copia corretta
e funzionante del progetto. Da quella copia si parte con uno sviluppo.
Le modifiche saranno pushate sul server di backup, dal quale saranno
fatti anche i test.
In pratica se si parte da zero con un progetto si pulla dal master,
se invece il dev dovesse perdere la copia locale del repository (dato
che si parla di VCS distribuiti, ogni dev ha la sua copia in locale)
si può fare il pull dal backup, in modo da ritrovarsi con tutte le
modifiche senza ripartire dal master.
developer <- pull <- server master
modifiche del dev
developer -> push (automaticamente sul backup)
sul backup avrò un hooks che copia le modifiche su un
virtualhost di apache configurato sullo stesso server.
In questo modo, quando un dev fa il suo push, git copierà le
modifiche di ciascun dev in un vhost dedicato (
dev1.dominio.it
)
per permetterne i test.
Se tutto funziona, IO prenderò l'ultimo commit fatto dal dev sul
server di backup per unirlo al server master.
(fare il merge di un determinato commit/branch sul master, significa
portarsi dietro a ritroso anche tutte le altre modifiche fatte in
precedenza? Presumo di si, perchè se il dev facesse 5 commit, 
modificando su ciascun commit un solo file, io devo poter fare il merge
di tutti e 5 i file partendo dall'ultimo tag/branch/commit)
(oggi dovrebbero arrivare i libri, mi aspetterà un weekend di studio e 
prove)