Un post très rapide pour gérer son repository svn d'un projet. La vanne foireuse de mon titre est une phrase que je me suis dit la première fois que j'ai vu un repository svn. Au final cela ne demande pas grande connaissance quelques commandes et de la logique.
Organisation du dépôt
On crée le dépot rep, on fait un checkout de celui-ci dans une copie de travail "work", puis on crée les 3 répertoires de notre organisation.
ioo@particules:~/test$ mkdir rep work ioo@particules:~/test$ svnadmin create rep ioo@particules:~/test$ svn co file:///home/ioo/test/rep/ work/ Révision 0 extraite. ioo@particules:~/test$ svn mkdir work/branches work/tags work/trunk A work/branches A work/tags A work/trunk ioo@particules:~/test$ svn ci -m "mise en place svn" work/ Ajout work/branches Ajout work/tags Ajout work/trunk Révision 1 propagée.
Bien évidement si votre projet ne va pas durer, même pas besoin d'un trunk, mais bon pour l'exemple, imaginons que vous vous lancez dans un framework[1]
Utilisation des tags
Vous faites donc un magnifique framework.txt et mettez vos fichiers dans trunk au départ
ioo@particules:~/test$ cd work/trunk ioo@particules:~/test/work/trunk$ touch framework.txt ioo@particules:~/test/work/trunk$ echo MVC > !:1 ioo@particules:~/test/work/trunk$ svn add framework.txt A framework.txt ioo@particules:~/test/work/trunk$ svn ci -m "ajout de mon framework" Ajout trunk/framework.txt Transmission des données . Révision 2 propagée.
Je vous ai fait une petite basherie comme ça gratos ! Maintenant cette première version de votre framework vous créez une release parce-qu'elle est stable et que vous voulez la déployez. Il suffit de copier avec svn le contenu du répertoire trunk dans tags. Notez le "trunk" sans "/" à la fin
ioo@particules:~/test/work$ cd .. ioo@particules:~/test/work$ svn copy trunk tags/release_1 A tags/release_1 ioo@particules:~/test/work$ svn ci -m "création release 1" Ajout tags/release_1 Ajout tags/release_1/framework.txt Transmission des données ... Révision 3 propagée.
Utilisation des branches
Maintenant imaginez que vous prévoyez de modifier votre framework en lui donnant une vraie structure MVC "model.txt" "view.txt" et "controller.txt"[2] Vous vous retrouvez avec deux versions à gérer avec deux développements distincts.
Vous créez votre branche 1.0 à partir du "trunk"[3] et votre nouvelle branches 2.0 directement.
ioo@particules:~/test/work$ svn copy trunk branches/1.0 A branches/1.0 ioo@particules:~/test/work$ svn mkdir branches/2.0 A branches/2.0 ioo@particules:~/test/work$ svn ci -m "créations des branches de dev" Ajout branches/1.0 Ajout branches/1.0/framework.txt Ajout branches/2.0 Révision 4 propagée.
Vous pouvez tranquillement créer votre nouvelle version de framework
ioo@particules:~/test/work$ touch branches/2.0/model.txt branches/2.0/view.txt branches/2.0/controller.txt ioo@particules:~/test/work$ svn add branches/2.0/* A branches/2.0/controller.txt A branches/2.0/model.txt A branches/2.0/view.txt ioo@particules:~/test/work$ svn ci -m "dev de ma branche 2" Ajout branches/2.0/controller.txt Ajout branches/2.0/model.txt Ajout branches/2.0/view.txt Transmission des données ... Révision 5 propagée.
Mais c'est pas fini....va falloir merger !
Et oui en faisant comme cela vous pouvez avoir de gros problèmes, je sais pas quelqu'un qui continue à travailler dans le "trunk" et qui clôture sympathiquement vos tickets.
ioo@particules:~/test/work$ echo changements > trunk/framework.txt ioo@particules:~/test/work$ touch trunk/addons.txt ioo@particules:~/test/work$ svn add trunk/addons.txt A trunk/addons.txt ioo@particules:~/test/work$ svn ci -m "correction bug #211" Ajout trunk/addons.txt Envoi trunk/framework.txt Transmission des données .. Révision 6 propagée.
Le travail est comité mais ceux qui utilise la branche n'est bénéficie pas. Zéro stress, le merge est l'arme fatale. Commencez par un update c'est mieux.
ioo@particules:~/test/work$ svn update À la révision 6.
Votre cible est le dossier de la branche 1.0 de votre copie de travail et votre source le dossier trunk du repository On regarde la révision à laquelle est notre branche sur notre copie de travail grâce à la commande svn info
ioo@particules:~/test/work$ svn info branches/1.0/ Chemin : branches/1.0 URL : file:///home/ioo/test/rep/branches/1.0 Racine du dépôt : file:///home/ioo/test/rep Révision : 6 Type de noeud : répertoire Tâche programmée : normale Auteur de la dernière modification : ioo Révision de la dernière modification : 4 Date de la dernière modification: 2009-03-31 00:35:14 +0200 (mar, 31 mar 2009)
Ce qui nous intéresse ici c'est Révision de la dernière modification qui est 4 et non Révision 6 qui est la révision du repository..
Il faut donc prendre les fichiers du repository qui sont à la dernière version et les merger avec la branches[4]
ioo@particules:~/test/work$ svn merge -r 4:HEAD file:///home/ioo/test/rep/trunk/ branches/1.0/ A branches/1.0/addons.txt U branches/1.0/framework.txt
L'option -r donne les numéros de révision, en premier la révision de la cible et le "HEAD" indique de prendre la dernière révision sur le répository. Vous pouvez indiquer un numéro de révision également. La suite de la commande est composée de la source et de la cible. Vous pouvez comitter les changement du dépot, effacer le trunk de votre copie de travail et du dépot également.
ioo@particules:~/test/work$ svn ci -m "merge du trunk et de la branche 1.0" Ajout branches/1.0/addons.txt Envoi branches/1.0/framework.txt Transmission des données . Révision 7 propagée. ioo@particules:~/test/work$ svn delete trunk/ D trunk/addons.txt D trunk/framework.txt D trunk ioo@particules:~/test/work$ svn ci -m "suppression du trunk" Suppression trunk Révision 8 propagée.
Et voilà un gros kamehameha sur votre trunk et votre repository est tout propre. Vous avez sauvé vos dev d'un passage en super sayan furax !
Comments
7 comments
Merci ioO pour l'effort de rédaction, c'est clair que c'est un sujet de l'ordre du "ben tout le monde connais trunk/tags/branches voyons!" mais qui au final n'est pas assez commenté. La documentation est bonne mais les points de vue d'utilisateurs de SCMs ne sont pas assez nombreux. Un post très utile AMHA ! :)
A propos de la gestion des branches, qui reste une question d'habitudes et d'adaptation à chaque projet, j'aurais un point de vue différent sur ton scenarii.
Admetons que tu décide d'appliquer à ton projet un "changement générationel" le faisant passer du stade Z au stade GT par exemple :), de la génération 1 à la 2 dans ton exemple. Selon la nature des changements je procéderai différement.
Par exemple si la version 1 vera son développement continuer avant d'arriver à qque chose de l'ordre d'une ALPHA de la version 2, le ferais le développement de la version 2 dans une branche, le trunk restant à la version 1. Je mergerai régulièrement les corrections appliquées à la version 1 dans ma branche 2. Lorsque j'estime que la version 2 deviens celle de développement principal, à la dernière release de la 1 (ie. 1.666) je brancherai la 1 et copierai directement la branche 2 dans trunk. Pour finir la branche 2 peut être supprimée.
Si au contraire le développement de la version 1 sera sporadique, le ferais l'inverse : une branche pour la 1 et le développement de la 2 dans trunk. Les releases suivantes de la v1 se faisant depuis la branche 1.
Un autre aspect sujet à de longues discussions est le placement du noeud trunk/tags/branches dans l'arborescence d'un repository, dans l'arborscence de multiples projets :)
Merci eskatos pour le commentaire.
Ton approche a plus de chance de se présenter que la mienne sur un même projet. L'exemple de mon article simplifie cette transition entre les branches d'un même projet pour montrer les différences entre branches et tags.
J'avais en tête un second article qui traite d'une transition plus "naturelle" pour introduire également svn:external. Mais on arrive vite à une limite, le cas d'utilisation dépend du projet.
Salut,
Je me permet de te mettre un lien vers un de mes post ou je n'ai malheureusement pas eu de réponses.
http://www.developpez.net/forums/d7...
En lisant ton ticket et les 2 commentaires je m'appercois qu'il suffirait que je fasses les modifications sur ma branches et que je fasse un merge avec mon trunk pour que mes corrections de bug se fassent automatiquement ?
Merci d'avance.
Salut Scalp,
Tu dois utiliser la commande svn merge pour appliquer les corrections de bugs de branches vers trunk.
Cependant tu te compliques la tâche. Que ce soit ta branche ou ton trunk, les dossiers contiennent le même projet. Tu maintiens la même version dans 2 dossiers différents, ce qui te fait jongler de l'un à l'autre.
Conserves le trunk ou la branche, et développe à partir d'un seul dossier.
Que ce soit des corrections de bugs ou des évolutions, que cela arrive disséminé ou dans un temps plus restreint, cela concerne ton projet de départ.
Salut ioO,
Je reviens vers toi après pas mal de temps.
Je pense avoir maintenant un peu mieux compris le système, mais j'aimerais être sur de l'utiliser correctement, malgré que comme l'a dit Eskatos, je pense que certaine gestions varient en fonction des projets.
En gros, pour prendre un cas concret, si on prend le svn de Symfony.
On voit qu'ils n'y a plus de trunk mais juste branches/tags. En suivant ton raisonnement, ils seraient plus arrivé à une structure contenant 1 trunk contenant la 1.3, et 3 branches (1.0/1.1/1.2) ?
En sachant que si un bug apparaissait sur la 1.2 par exemple, il suffirait d'aller corriger le bug sur la branches/1.2, puis de faire un merge sur toutes les autres branches dans leur cas et sur toutes les autres branches et le trunk si on suit la structure de ton billet ?
Ai-je bon ? C'est assez facile de s'emmêler les pinceaux avec ce Sangoku... ;-)
Merci d'avance.
Salut Scalp,
>On voit qu'ils n'y a plus de trunk mais juste branches/tags. En suivant ton raisonnement, ils seraient plus arrivé à une structure contenant 1 trunk contenant la 1.3, et 3 branches (1.0/1.1/1.2) ?
Justement c'est plus le propos d'eskatos d'avoir toujours un trunk ;-) Mais sinon oui le dépôt aurait cette structure.
C'est pour cela que je préfère l'utilisation des branches plutôt que la conservation du trunk, au moins tu nommes tes branches avec tes numéros de version.
Le point commun c'est que nous avons une version soit dans le trunk soit dans la branche, mais jamais dans les deux en même temps.
Pour l'application de la correction de bug, oui c'est ça tu l'appliques à un endroit du dépôt et tu merge ta correction avec les autres branches qui en ont besoin.
A+
Ok, merci de ta réponse !