Abbiamo visto in qualche articolo precedente come utilizare Bazaar, il CVS di Launchpad, per gestire il nostro codice e upparlo sul server remoto. All’epoca però avevo volutamente tralasciato due punti per questioni di spazio: come creare un progetto su Launchpad e, soprattutto, come gestirlo fra più utenti. Due cose che, per chi usa Bazaar per piccoli progetti personali, non hanno molta importanza ma diventano indispensabili per chi vuole sviluppare un progetto in collaborazione con più persone.
La prima cosa da fare è sicuramente registrarsi su Launchpad. La registrazione è molto semplice e non penso necessiti di ulteriori spiegazioni.
Una volta che abbiamo il nostro utente è necessario configurare una chiave RSA per il collegamento sicuro SSH. Per fare questo dobbiamo aprire il terminale e digitare:
$ ssh-keygen
E seguire le istruzioni. Una volta completato avremo il file id_rsa.pub con la nostra chiave pubblica nella cartella .ssh all’interno della nostra Home. Fatto questo andiamo sul nostro profilo in Launchpad, individuiamo la voce SSH Keys e clicchiamo sul bollino giallo a fianco. Noterete una casella di testo piuttosto grande: copiate lì il contenuto del file id_rsa.pub e data infine Import Public Key.
Ora siete pronti per creare il progetto. Anche qui la procedura è semplice: dalla Home Page di Launchpad, sotto Get Started, troverete il link per Create new project. Cliccateci sopra ed inserite le informazioniche vichiede, sono tutte molto ovvie, nome, descrizione del progetto, url e via dicendo.
Avrete a disposizione ora la nuova pagina per il vostro progetto.
La prima cosa da fare è creare una series. Una serie non è altro che una “corrente” di sviluppo. Progetti complessi hanno solitamente più series: la trunk che contiene gli ultimi sviluppi, una series per laversione 0.5, una series per la versione 0.6 e così via. All’inizio vi conviene partire con la serie base, la trunk. Createla.
Una volta creata la serie dovete creare un branches o ramo. I rami corrispondono a vari percorsi di sviluppo all’interno della stessa serie. Se le series indicano qual’è il fine di un percorso di sviluppo, i branches rappresentano le varie strade che conducono a tale fine. Infatti, solitamente , tutti i rami di una serie, alla fine del ciclo di sviluppo, o vengono eliminati o si riuniscono nella cosiddetta versione “stable”.
Creato il vostro ramo (che solitamente essendo il principale si chiama, con molta fantasia, main) potete uppare il vostro progetto con bazaar come spiegato nell’apposita guida. In generale basta il comando:
$ bzr push lp:~userid/project-name/branch-name
Se non sapete come usare bazaar datevi una letta alla pratica guida.
Ora è il momento di scegliere come far collaborare il gruppo al progetto. Esistono infatti 3 approcci differenti:
- Centralizzato: Tutti i membri del gruppo inviano i propri commit direttamente sul server remoto (meccanismo di Subversion).
- Centralizzato con commit locali: Ogni membro commissiona alcuni commit locali e, quando è pronto, invia sul server remoto tutti i commit in un solo colpo (meccanismo di Git).
- Decentralizzato con guida condivisa: Ogni utente ha il proprio ramo di sviluppo che all’occorrenza viene “fuso” con un ramo principale (main).
In questa guida spiegherò il meccanismo più semplice e intuitivo. Il centralizzato.
Il meccanismo centralizzato è il più semplice ma anche il più rigido dei meccanismi. Si adatta bene a gruppi non molto numerosi e che possono facilmente tenersi in contatto. In gruppi troppo numerosi infatti la possibilità di conflitti cresce esponenzialmente.
Per spiegare questo meccanismo supponiamo che ci sia un gruppo di sviluppo composto da tre utenti: L, Q e H. (messaggio subliminale).
- I tre membri creano un team, che si chiama casualmente proprio LQH, cliccando l’apposito link nell’home di Launchpad (non penso sia complicato ma se avete difficoltà ditemelo che aggiungerò questa parte).
- Tutti e tre i membri devono effettuare il checkout del progetto. Per fare ciò si aprono il terminale nella cartella dei loro progetti e digitano:
$ bzr checkout lp:team-name/project-name/branch-name
- L decide di effettuare alcune modifiche al codice. Le fa tranquillamente e alla fine commissiona con
$ bzr commit -m "Messaggio"
- Q e H a questo punto possono aggiornare la loro cartella con
$ bzr update
- Se Q o H avessero fatto modifiche al codice prima dell’update le due verisone verrebbero “fuse”. Nonostante ciò è possibile che si verifichino dei conflitti. Questi vanno risolti (spesso a mano) prima di effettuare nuovamente l’update.
Questo è il meccanismo base con il quale potete organizzare un progetto su Launchpad con Bazaar. Ovviamente ci sono piccoli trucchi che imparerete col tempo che miglioreranno la vostra produttività.
Qui mi sono già dilungato troppo. Se ci sono problemi tornerò volentieri sull’argomento.
ciao davide
sono un tuo lettore fin dalla nascita del blog, le tue guide le ritengo molto interessanti e utili. mi è piaciuta molto la serie introduttiva ai concetti della programmazione. so che avevi in mente di fare una versione .pdf e la sto aspettando con ansia da diverso tempo. adesso non sono quì a costringerti a continuare la stesura, però ti do giusto lo stimolo per continuarne la stesura, perchè davvero ottima. fine 🙂 ad ogni modo, auguri per il blog e complimenti per l’ottimo lavoro che hai svolto 🙂 continua così. ciao
ps: so che hai usato archlinux, e adesso usi sidux. ma come fa a non mancarti? 😀
Grazie infinite!!! 😀
Non l’ho interrotta, ho messo tutto quello che è uscito fin’ora più alcuni ampliamenti. Solo che ora sto dando la tesi e fra LQH e qualche guida ho poco tempo da dedicargli. Penso che entro la fine dell’anno ricomincierò a pieno ritmo e rilascerò una seconda bozza.
Ho usato arch ed è molto bella ma: volevo usare la stessa distro sia in ambienti che necessitano elevata stabilità sia in ambienti di test, volevo una distro che si istalla e diventa pienamente operativa in venti minuti, ho collaborato con il team di Debian per qualche pacchetto…. inoltre Debian resta Debian. Arch rimane la mia seconda scelta 😉
già, debian è sempre debian, anche se ritengo archlinux ugualmente stabile, ma più aggiornata. poi è molto più comunitaria, imo 😀 comunque ottima notizia, non vedo l’ora di avere tra i “blocchi di memoria” questa RC2 xD
maaaaa…avevi rilasciato un RC1? d’oh!
Beh Sidux è anche troppo aggiornata xD Ogni tanto ti sparisce Xorg per un aggiornamento “troppo frettoloso”.
Si esisteva una versione 1 ma era molto incompleta, serviva giusto a rendere l’idea…