====== SubVersion ======

Le site officiel : http://subversion.apache.org (anciennement http://subversion.tigris.org) \\
et son [[http://www.svnforum.org/|Forum]]

La doc : http://svnbook.red-bean.com/

Des tutos :
  * Le tuto de [[http://conception.developpez.com/faq/scm/|developpez.com]]
  * [[http://dev.nozav.org/intro_svn.html|Introduction à Subversion]] par julien@nozav@org

===== Outils =====

Client windows :
  * [[informatique:TortoiseSVN]].

Interface Web d'administration de dépôts:
  * [[http://www.usvn.info|User-Friendly SVN (USVN)]] (fr!) en Php sur la base du Zend Framework. //J'ai pas réussi à l'installer, après le script d'install, il y avait des tables mais toutes vides, du coup impossible de se logger en admin...//
  * [[http://code.google.com/p/svn-web-admin|SVNWebAdmin]] en Java

===== Tips & Tricks =====

====Revenir à une version antérieure====

Cela fait un moment que je travaille sur le même projet en faisant des branches, des tags... Je fais des "commit" réguliers. Et tout à coup, arrivant à la révision 2347 je me suis apperçu que j'avais introduit, par mégarde, un nouveau bug qui n'était pas présent à la révision 2346.

La question qui est sur toutes les lèvres: comment revenir facilement à la révision précédente ? Et bien rien de plus simple, il suffit de taper la commande suivante:

svn merge -r2347:2346 URL .

Deux remarques:
    * c'est bien la commande merge qu'il faut utiliser; c'est clairement écrit dans la documentation.
    * je ne me suis pas trompé; les numéros de révisions sont dans l'ordre décroissant contrairement à un merge "classique". Mais en y réfléchissant bien, c'est logique, on veut bien passer de la révision 2347 à la révision 2346

Il ne reste plus qu'à faire un commit.

====Nettoyer les .svn====

J'ai copié une working copy en production et j'ai tous les répertoires .svn ... Comment les effacer ?

  find ./repertoireDeDepart -type d -name ".svn" | xargs rm -rf

==== Freeze des externals ====

Afin de bénéficier facilement des plugins développés dans les différentes applications, nous utilisons une fonctionnalité du gestionnaire de source : la propriété "[[http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html|svn:externals]]". Cette propriété permet de faire référence à un autre endroit du dépôt ou à un dépôt externe qui sera automatiquement remonté lors du checkout et des updates. On a donc pour chaque déclinaison de site, une application qui référence via des "svn:externals" les plugins communs. Chaque déclinaison peut surcharger leurs fonctionnalités dans les répertoires qui leurs sont propres.

Afin de pouvoir garantir la cohérence entre les différentes versions et sécuriser déploiement, maintenance et montées de version, les conventions branches et tags classiques de Subversion peuvent être appliquées. Ces conventions doivent être utilisées à la fois pour les plugins et pour les applications. Il suffit alors de faire pointer les svn:externals vers des branches/tags particuliers pour s’assurer de la maîtrise de l’application.

Nous avons baptisé cette procédure le "freeze" des externals. Elle consiste, lorsqu’on tagge une application, à modifier les références dans les externals afin de ne plus remonter les mises à jours de plugins lors de futurs "svn up". Deux méthodes sont envisageables :

  * modification des chemins de "svn:externals" pour pointer vers le tag correspondant
  * "svn copy" des plugins internes vers le tags de notre application. On obtient une structure cohérente avec tout le code intégré et on bénéficie de l’historique des plugins grâce au svn copy. Les plugins externes peuvent être rapatriés par un "svn export".

Lire la suite: [[http://www.clever-age.com/veille/blog/industrialisation-de-projets-multi-sites.html|Organisation des sources]]