| corso Symfony a Roma
Suggerimento
Questa voce è specifica per Subversion e si basa sui principi di Come creare e memorizzare un progetto Symfony2 in git.
Una volta letto Creare pagine in Symfony2 e aver preso familiarità con l’uso di Symfony, si è senza dubbio pronti per iniziare il proprio progetto. Il metodo preferito per gestire progetti Symfony2 è l’uso di git, ma qualcuno preferisce usare Subversion, che va totalmente bene! In questa ricetta, vedremo come gestire il proprio progetto usando svn, in modo simile a quanto si farebbe con git.
Suggerimento
Questo è un metodo per memorizzare il proprio progetto Symfony2 in un repository Subversion. Ci sono molti modi di farlo e questo è semplicemente uno che funziona.
Per questa ricetta, supporremo che lo schema del repository segua la struttura standard, molto diffusa:
mio_progetto/
branches/
tags/
trunk/
Suggerimento
La maggior parte degli host con subversion dovrebbero seguire questa pratica. Questo è lo schema raccomandato in Controllo di versione con Subversion e quello usato da quasi tutti gli host gratuiti (vedere Soluzioni di hosting subversion).
Per iniziare, occorre scaricare Symfony2 e preparare Subversion:
Scaricare Symfony2 Standard Edition, con o senza venditori.
Scompattare la distribuzione. Questo creerà una cartella chiamata Symfony, con la struttura del nuovo progetto, i file di configurazione, ecc. Rinominarla con il nome che si desidera.
Eseguire il checkout del repository Subversion che ospiterà questo progetto. Supponiamo che sia ospitato su Google code e che si chiami mioprogetto:
$ svn checkout http://mioprogetto.googlecode.com/svn/trunk mioprogetto
Copiare i file del progetto Symfony2 nella cartella di subversion:
$ mv Symfony/* mioprogetto/
Impostiamo ora le regole di ignore. Non tutto andrebbe memorizzato nel repository subversion. Alcuni file (come la cache) sono generati e altri (come la configurazione del database) devono essere personalizzati su ciascuna macchina. Ciò implica l’uso della proprietà svn:ignore, che consente di ignorare specifici file.
$ cd mioprogetto/
$ svn add --depth=empty app app/cache app/logs app/config web
$ svn propset svn:ignore "vendor" .
$ svn propset svn:ignore "bootstrap*" app/
$ svn propset svn:ignore "parameters.ini" app/config/
$ svn propset svn:ignore "*" app/cache/
$ svn propset svn:ignore "*" app/logs/
$ svn propset svn:ignore "bundles" web
$ svn ci -m "commit della lista di ignore di Symfony (vendor, app/bootstrap*, app/config/parameters.ini, app/cache/*, app/logs/*, web/bundles)"
Tutti gli altri file possono essere aggiunti al progetto:
$ svn add --force .
$ svn ci -m "aggiunta Symfony Standard 2.X.Y"
Copiare app/config/parameters.ini su app/config/parameters.ini.dist. Il file parameters.ini è ignorato da svn (vedere sopra) in modo che le impostazioni delle singole macchine, come le password del database, non siano inserite. Creando il file parameters.ini.dist, i nuovi sviluppatori possono prendere subito il progetto, copiare questo file in parameters.ini, personalizzarlo e iniziare a sviluppare.
Infine, scaricare tutte le librerie dei venditori:
$ php bin/vendors install
Suggerimento
git deve essere installato per poter eseguire bin/vendors, essendo il protocollo usato per recuperare le librerie. Questo vuol dire che git è usato solo come strumento per poter scaricare le librerie nella cartella vendor/.
A questo punto, si ha un progetto Symfony2 pienamente funzionante, memorizzato nel proprio repository Subversion. Si può iniziare lo sviluppo, con i commit verso il repository.
Si può continuare a seguire il capitolo Creare pagine in Symfony2 per imparare di più su come configurare e sviluppare la propria applicazione.
Suggerimento
La Standard Edition di Symfony2 ha alcune funzionalità di esempio. Per rimuovere il codice di esempio, seguire le istruzioni nel Readme della Standard Edition.
### Come funziona?
Ogni progetto Symfony usa un gruppo di librerie di “venditori”. In un modo o nell’altro, lo scopo è scaricare tali file nella propria cartella vendor/ e, idealmente, avere un modo tranquillo per gestire l’esatta versione necessaria per ciascuno.
Per impostazione predefinita, tali librerie sono scaricate eseguendo uno script “scaricatore” php bin/vendors install. Questo script legge dal file deps nella radice del proprio progetto. Questo è uno script in formato ini, che contiene una lista di ogni libreria necessaria, la cartella in cui ognuna va scaricata e (opzionalmente) la versione da scaricare. Lo script bin/vendors usa git per scaricare, solamente perché queste librerie esterne solitamente sono memorizzate tramite git. Lo script bin/vendors legge anche il file deps.lock, che consente di bloccare ogni libreria a un preciso hash di commit.
È importante capire che queste librerie di venditori non sono in realtà parte del proprio repository. Sono invece dei semplici file non tracciati, che sono scaricati dallo script bin/vendors nella cartella vendor/. Ma, poiché ogni informazione necessaria a scaricare tali file è nei file deps e deps.lock (che sono memorizzati nel proprio repository), ogni altro sviluppatore può usare il progetto, eseguendo php bin/vendors install e scaricando lo stesso preciso insieme di librerie di venditori. Questo vuol dire che si può controllare con precisione ogni libreria di venditore, senza dover in realtà inserirle nel proprio repository.
Quindi, ogni volta che uno sviluppatore usa il progetto, deve eseguire lo script php bin/vendors install, per assicurarsi di avere tutte le librerie necessarie.
Attenzione
C’è anche un comando php bin/vendors update, ma non ha niente a che fare con l’aggiornamento del progetto e solitamente non sarà necessario usarlo. Questo comando è usato per congelare le versioni di tutte le librerie dei venditori, aggiornandole alle versioni specificate in deps e registrandole nel file deps.lock.
### Modificare le librerie dei venditori
A volte, si ha bisogno di un ramo specifico, oppure di un tag o di un commit di una libreria. Lo si può impostare direttamente nel file deps:
[AcmeAwesomeBundle]
git=http://github.com/johndoe/Acme/AwesomeBundle.git
target=/bundles/Acme/AwesomeBundle
version=una-versione-aggiornata
### Flusso di aggiornamento
Quando si esegue php bin/vendors install, per ogni libreria, lo script verifica prima se esiste la cartella di installazione.
Se non esiste (e SOLO se non esiste), esegue un git clone.
Quindi, esegue un git fetch origin e un git reset --hard la-mia-versione.
Questo vuole dire che il repository sarà clonato una sola volta. Se si vuole eseguire una modifica sui remote di git, si DEVE cancellare l’intera cartella di destionazione, non solo il suo contenuto.
La differenza maggiore tra git e svn è che Subversion necessita di un repository centrale per funzionare. Ci sono diverse soluzioni: