(post limite pense bête)
Voici la configuration SVN que j’utilise pour un projet Symfony 1.0 :
/
svn:ignore
.*
/cache
svn:ignore
*
/config
svn:ignore
databases.yml
propel.ini
generated-*
/data
svn:externals
symfony http://svn.symfony-project.com/tags/RELEASE_1_0_16/data/
/data/sql
svn:ignore
lib.model.schema.sql
sqldb.map
/lib
svn:externals
symfony http://svn.symfony-project.com/tags/RELEASE_1_0_16/lib/
/lib/model
svn:ignore
map
om
/log
svn:ignore
*
/plugins
svn:externals
sfJqueryPlugin http://svn.symfony-project.com/plugins/sfJqueryPlugin
/web
svn:externals
sf http://svn.symfony-project.com/tags/RELEASE_1_0_16/data/web/sf/
/web/uploads
svn:ignore
*
Pour les plugins bien sur, on ajoute ceux que l’on veut. Si on ne commite pas databases.yml et propel.ini, en général on commite des copies nommées databases.yml-dist et propel.ini-dist histoire de faciliter la vie des développeurs.
Vous voyez d’autres points ?
Merci pour ce pense-bête bien pratique.
Une petite remarque, dans /config tu devrais ignorer plutôt « generated-* » car certains plugins génèrent des fichiers de ce type au build.
Tu devrais linker la branche plutôt que le tag, comme ça les updates de sécurité ne nécessitent qu’un svn up plutôt qu’un hasardeux svn relocate.
Sinon moi je met tout symfony dans ./lib/vendor/symfony, avec l’autoloading ça roule et en plus je peux lancer les tests unitaires de symfony d’un coup de php lib/vendor/symfony/test/bin/prove.php 🙂
@Matt : corrigé
@Niko : changer un external n’implique pas un svn relocate (d’ailleurs pourquoi tu dis que c’est hasardeux …). Ca remplace juste les fichiers. Le soucis sur le branchement sur une branche est que je ne sais pas si un commit dessus correspond à un update de sécurité ou à un travail en cours des mainteneurs de la branche. Peut être es tu au courant ? Je préfère pour cela me caler sur des releases.
Merci pour la précision sur le répertoire vendor, je ne connaissais pas !
Je voulais parler d’un switch plutôt qu’un relocate, mais effectivement changer l’external à la mano fonctionne, mon méat coule pas.
Par contre le switch –relocate est une opération délicate si on se gourre, c’est généralement au final un dépôt mort qu’il faut essayer de réanimer à grand coups de sed (experience inside o/)
Heu sinon, oui les branches, une fois la version stable sortie, ne concerne toujours *que* les patches de sécurité et ne cassent pas l’API.
C’est tout l’intérêt d’une branche stable 🙂
ok merci NiKo. Juste pour savoir, les développeurs qui soumettent des patchs sur la branche stable, comment ont ils fait au préalable pour valider ce patch avec la communauté ?
Les choses sont discutées au sein même des tickets où parfois sur la mailing list, pour les failles rportées tout se fait sur une mailing list interne à la core team (qui n’inclue pas que des gens de chez Sensio, mais aussi Yahoo! ou autres)
Sans prétention, mais bien utile le Blog 🙂
Y aurait il des nouveaux points de configuration pour la 1.4 ? Je mene l’enquête et je vous tiens au courant !!!