Voici un petit récap pour utiliser les branches de développement lorsque le code source est géré avec SVN.

Cet exemple est une version simplifiée/clarifiée d’un PowerPoint, disponible ici : http://subversion.tigris.org/servlets/ProjectDocumentList

Developer copies trunk to a new branch and notes revision of trunk

% svn cp –m “Creating branch” http://my.repository.com/trunk http://my.repository.com/branches/MY-BRANCHE

% svn log -v http://my.repository.com/branches/MY-BRANCHE
# Prints revision number, say 123

% svn co http://my.repository.com/branches/MY-BRANCHE

Work progresses in the branch. Time to merge work into trunk. But first, merge trunk changes to branch

% svn merge –r 123:HEAD http://my.repository.com/trunk .
# Test new code.

% svn commit –m "message"
# Revision 256.

Tree admin now merge changes into trunk

% cd /tmp
% svn co http://my.repository.com/trunk
% cd project
% svn merge . http://my.repository.com/branches/MY-BRANCHE
% svn commit –m "message"

Commentaires

Jamal Abdou-Karim Bengeloun 2009-08-05 10:18:09

J’utilise git chez moi et pour des projets où j’ai la main sur tout. En entreprise (comme la version Entreprise d’un logiciel - qui ne veut rien dire au final), déjà les faire passer à subversion, c’était de la gymnastique de haut niveau… Alors git (ou mercurial)… Mais vous êtes fou?

Jamal Abdou-Karim Bengeloun 2009-08-04 21:17:47

Yes but of course… Aber, ça c’est quand tout va bien dans le meilleur des mondes très cher.

Pour ma part, vu que je travaille avec symfony 1.0 dans une banque… Pas suisse pourtant, mais entre ceux qui sont partis en vacances, ceux qui aiment faire traîner quand les modifications demandées ont été livrées alors qu’avant qu’elles le soient, c’était super mega urgent quelque chose de grave, ceux à qui on devrait interdire de faire des demandes parce qu’à part les faire, c’est tout ce qu’ils savent faire (les valider boudiou, mais vous êtes fous!) - (moi et les parenthèses, faut suivre après) - Je me retrouve avec pleins de fichiers sur la plateforme de pré-production (the staging environment, lol!) avec des fichiers (je précisais symfony parce que niveau fichiers, c’est la diahrée chronique, lol!), qu’il faut livrer, d’autres qu’il ne faut surtout pas livrer, d’autre que bon s’ils passent en production, y a pas mort d’homme, mais quand même.

Donc là, le seul moyen, c’est de faire un check out de la version de base dans un répertoire à part (pas celui de travail sinon après c’est le bordel et le switch de toute façon ne suivra pas ces acrobaties) et de s’amuser à faire:

svn merge -r version1:version2 svnUrl

exemple: svn merge -r 1251:1253 http://svn/php/extranet/trunk .

L’avantage, c’est de pouvoir livrer précisemment ce que l’on veut en “sautant” si nécessaire les modifications à ne pas livrer quitte à effectuer la manoeuvre plusieurs fois de suite. Pas très agile (les technologies agiles ont du bon, mais tant qu’on aura pas dressé les utilisateur[dans le sens service informatique pas clients] à être agiles aussi…) ni élégant comme procédé mais ça marche.

Pour finir, on pourra “nettoyer” la copie locale ainsi construite et en faire une livraison avec un:

svn import -m "ouf!" http://svn/php/extranet/tags/2.8.1

Ah oui, tu as oublié de précisé que quand on a mis des “bêtises” dans le repo, le moyen de réparer, c’est de faire un merge version back to the future sur la copie locale et ensuite d’effectuer un commit pour écraser les modifications incriminés (salutaire quand un de tes collèges qui n’est pas copain avec subversion, la ligne de commande ou l’informatique en général fait un ch’tit clic droit sur tortoiseSVN):

svn merge -r version2:version1 http://svn/pb/batchs

Jérémy Lecour 2009-08-04 23:00:49

Depuis plusieurs mois, je suis passé à Git et sincèrement, ma vie a changé. La gestion des branches est ultra simple.

http://git-scm.com/ http://whygitisbetterthanx.com/