Créer un projet Symfony à partir des dépôts Subversion sous Ubuntu
Par NiKo le mercredi 7 février 2007, 08:02 - Dev
- Lien permanent -
8 commentaires -
Tags :
Un des gros avantages du framework Symfony, c'est qu'il est régulièrement mis à jour. En ce sens, l'utilisation de liaisons externes Subversion permet de s'affranchir des opérations récurrentes de mise à jour manuelles du code du framework.
Seul prérequis pour mettre en oeuvre la technique décrite ci-après, avoir accès à un dépôt Subversion pour y stocker son propre projet personnel.
Voyons donc comment créer un projet Symfony from scratch à partir des sources du dépôt officiel, sous Ubuntu par exemple...
Conventions
Nous admettrons que nous avons mis en place un dépôt Subversion et que celui-ci est accessible à l'URL http://trac.mondomaine.tld/svn/monprojet.
Création du projet subversion
$ mkdir monprojet && cd monprojet
On versionne notre projet nouvellement créé dans Subversion et on en fait un checkout en suivant :
$ echo "Mon projet README" > README $ svn import -m "Initial import" . http://trac.mondomaine.tld/svn/monprojet $ rm README && svn co http://trac.mondomaine.tld/svn/monprojet .
Liaison des sources de Symfony
On récupère le contenu intégral du trunk de Symfony dans un répertoire virtuel vendor/symfony, grâce à un svn:externals :
$ mkdir vendor && svn add vendor $ svn propset svn:externals "symfony http://svn.symfony-project.com/trunk/" vendor
On commite :
$ svn commit -m "Added svn:externals to sf trunk in vendor/" vendor/
On oublie pas d'updater :
$ svn up
L'intégralité du trunk de Symfony est alors téléchargé en local (cela peut prendre un peu de temps).
Création du projet Symfony
Pour bien utiliser les capacités de Subversion par la suite, on créé un répertoire trunk dans lequel nous allons initialiser notre projet Symfony :
$ mkdir trunk && cd trunk $ ../vendor/symfony/data/bin/symfony init-project monprojet
De même, on crée en même temps les traditionnels répertoires branches et tags :
$ cd .. $ mkdir branches tags
Pour l'heure, un ls -l nous donne à la racine du projet subversion :
$ ls -l total 20 drwxr-xr-x 2 niko niko 4096 2007-02-07 17:02 branches -rw-r--r-- 1 niko niko 95 2007-02-07 16:47 README drwxr-xr-x 2 niko niko 4096 2007-02-07 17:02 tags drwxr-xr-x 13 niko niko 4096 2007-02-07 16:59 trunk drwxr-xr-x 4 niko niko 4096 2007-02-07 16:56 vendor
Configuration du projet Symfony
Il faut maintenant configurer le projet Symfony pour qu'il sâche trouver les librairies de base que nous avons précédemment récupéré - et surtout que le projet soit portable -, en éditant le fichier trunk/config/config.php :
$sf_symfony_lib_dir = dirname(__FILE__).'/../../vendor/symfony/lib'; $sf_symfony_data_dir = dirname(__FILE__).'/../../vendor/symfony/data';
On teste l'installation en lançant la commande ./symfony -T depuis la racine du projet Symfony :
$ cd trunk $ ./symfony -T
Si ça marche, on ajoute tout ce qui est nouveau fichier, et on commite en suivant :
$ cd ..
$ svn stat | grep ? | awk '{ print $2 }' | xargs svn add
$ svn commit -m "File structure created, sf project initialized" .
On pourra également faire un lien symbolique vers le répertoire web/sf, ou bien le définir en tant qu'alias dans le vhost apache :
<VirtualHost toto.monprojet.tld> (...) alias /sf /path/to/vendor/data/web/sf (...) </VirtualHost>
Conclusion
L'avantage de toutes ces manipulations est que désormais, un svn up mettra à jour non seulement les fichiers de notre application, mais également le framework en lui-même. Les éternels grincheux crieront au loup quand au danger de lier une version de développement (trunk), je leur répondrai qu'un svn:externals peut tout aussi bien pointer vers une révision ou un tag particulier.
Par exemple, si vous désirez éviter de lier le trunk de Symfony, vous pouvez lier la version 1.0RC2 en spécifiant son url dans votre svn:externals :
$ svn propset svn:externals "symfony http://svn.symfony-project.com/tags/RELEASE_1_0_0_rc2/" vendor
Pour la suite, je vous renvoie à la documentation officielle de Symfony 
8 commentaires (Ajouter un commentaire)
IL EST BEAU IL EST FORT CE NIKO.
J'ai mis le temps pour le pondre celui-là, mais ça y est
Je tiens à dire que c'est vachement dangereux de lier le dev d'une appli à une version de dev d'un framework ! Mettre en garde si tard le lecteur est une érésie. Puisque c'est comme ça, je lirais plus ce blog ! Na !
Plus sérieusement, c'est vrai que les externals, c'est bien pratique - je fais pareil avec django
En fait c'est surtout pour éviter l'installation via
FEARPEAR et permettre à chaque projet Symfony d'embarquer sa propre version du framework.On pourrait même pousser le vice jusqu'à versionner les fichiers du framework dans son propre dépôt pour pallier à d'éventuels dénis de service au niveau des serveurs de Symfony, en utilisant svnsync
Il y a quelquechose que je dois mal saisir à propos de subversion.
J'avais essayé il a quelques semaines, j'étais parvenu à créer un projet sur mon serveur à faire un checkout en local, à faire des commit...
Par contre, je ne parviens pas à comprendre ou sont situés les "vrais" fichiers, où dois je faire pointer mon virtualHost apache si je souhaite voir en direct les modifs effectués dans le cadre d'une aplli web ?
Celà est surement tout bête mais je n'avais pas réussi à comprendre ?
Tu peux pas le faire directement.
Tu auras par ex ton projet subversion dans /home/subversion/monprojet
Si ton document root apache est /home/www/monappli, il faudra que tu mettes en place un checkout de ton instance subversion dans /home/www/monappli.
jblanche : joli ton design de blog by the way
(faudra quand même que tu penses à éditer le lien de GetFirefox car c'est le même que Niko, hi hi hi
)
Ok merci pour l'astuce subversion, pour le design de mon blog j'avoue avoir "pompé" les 2 barres rouges de header et footer.
J'espère que ca ne pose pas de problème particulier (le reste est quand même bien différent), dans le cas contraire signale le moi et je changerais sans rechigné
Pour le lien firefox, je modifie ca dès ce soir.