Creare e memorizzare un progetto Symfony in Subversion

Suggerimento

Questa voce è specifica per Subversion e si basa sui principi di Creare e memorizzare un progetto Symfony in git.

Una volta letto Creare pagine in Symfony e aver preso familiarità con l’uso di Symfony, si è senza dubbio pronti per iniziare un progetto. Il metodo preferito per gestire progetti Symfony è l’uso di git, ma qualcuno preferisce usare Subversion, che va bene lo stesso! In questa ricetta, si vedrà come gestire un progetto usando svn, in modo simile a quanto si farebbe con git.

Suggerimento

Questo è un metodo per memorizzare un progetto Symfony in un repository Subversion. Ci sono molti modi di farlo e questo è semplicemente uno che funziona.

Il repository Subversion

Per questa ricetta, si suppone che lo schema del repository segua la struttura standard, molto diffusa:

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).

Preparazione del progetto

Per iniziare, occorre scaricare Symfony e preparare Subversion. Scaricare Symfony, seguendo il capitolo sull’installazione

Una volta ottenuta la cartella del progetto e tutto funziona, seguire questi passi:

  1. Eseguire il checkout del repository Subversion che ospiterà questo progetto. Supponiamo che sia ospitato su Google code e che si chiami progetto:

    $ svn checkout http://progetto.googlecode.com/svn/trunk progetto
    
  2. Copiare i file del progetto Symfony nella cartella di subversion:

    $ mv Symfony/* progetto/
    
  3. Impostare le regole di ignore. Non tutto andrebbe memorizzato nel repository subversion. Alcuni file (come la cache) sono generati e altri (come la configurazione della base dati) devono essere personalizzati su ciascuna macchina. Ciò implica l’uso della proprietà svn:ignore, che consente di ignorare specifici file.

    $ cd progetto/
    $ 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.yml" 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.yml, app/cache/*, app/logs/*, web/bundles)"
    
  4. 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.yml su app/config/parameters.yml.dist. Il file parameters.yml è ignorato da svn (vedere sopra) in modo che le impostazioni delle singole macchine, come le password della base dati, non siano inserite. Creando il file parameters.yml.dist, i nuovi sviluppatori possono prendere subito il progetto, copiare questo file in parameters.yml, personalizzarlo e iniziare a sviluppare.

A questo punto, si ha un progetto Symfony 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 Symfony per imparare di più su come configurare e sviluppare un’applicazione.

Suggerimento

La Standard Edition di Symfony ha alcune funzionalità di esempio. Per rimuovere il codice di esempio, seguire le istruzioni nella ricetta “Rimuovere AcmeDemoBundle”.

Gestire le librerie dei venditori con composer.json

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 composer.phar install. Questo file composer.phar fa parte di una libreria chiamata Composer, di cui si può approfondire l’uso in questo capitolo.

Il file composer.phar legge dal file composer.json, posto nella radice del progetto. Questo file, formattato in JSON, contiene una lista di ogni pacchetto esterno necessario, la sua versione e altro ancora. Il file composer.phar legge anche un file composer.lock, che consente di bloccare ogni libreria a una versione esatta. Di fatto se esiste un file composer.lock, le versioni in esso contenute sovrascrivono quelle in composer.json. Per aggiornare le librerie alle ultime versioni, eseguire php composer.phar update.

Suggerimento

Se si vuole aggiungere un nuovo pacchetto a un’applicazione, eseguire il comando require:

$ composer require doctrine/doctrine-fixtures-bundle

Per saperne di più su Composer, vedere GetComposer.org:

È 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 nella cartella vendor/. Ma, poiché ogni informazione necessaria a scaricare tali file è nei file composer.json e composer.lock (che sono memorizzati nel proprio repository), ogni altro sviluppatore può usare il progetto, eseguendo php composer.phar 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 composer.phar install, per assicurarsi di avere tutte le librerie necessarie.

Soluzioni di hosting subversion

La differenza maggiore tra git e svn è che Subversion necessita di un repository centrale per funzionare. Ci sono diverse soluzioni:

  • Hosting autonomo: creare il proprio repository e accedervi tramite filesystem o tramite rete. Per maggiori informazioni, leggere Controllo di versione con Subversion.
  • Hosting di terze parti: ci sono molte buone soluzioni di hosting gratuito a disposizione, come GitHub, Google code, SourceForge o Gna. Alcune di queste offrono anche hosting git.