Configuration SVN pour un projet Symfony

19 juin 2008 par Olivier Mansour

(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 ?

Dans Info et autres geekeries | 7 commentaires | Tags : >

Pour soutenir ce site, n'hésitez pas à cliquer sur un de ces liens :

  1. Par Matthieu le 19 juin 2008 | Répondre

    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.

  2. Par NiKo le 19 juin 2008 | Répondre

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

  3. Par Olivier Mansour le 21 juin 2008 | Répondre

    @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 !

  4. Par NiKo le 23 juin 2008 | Répondre

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

  5. Par NiKo le 23 juin 2008 | Répondre

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

  6. Par Olivier Mansour le 24 juin 2008 | Répondre

    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é ?

  7. Par NiKo le 29 juin 2008 | Répondre

    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)

Commentaires

RSS des commentaires pour ce post