Discussion :

[Kaldyris]

Bonjour à tous,
J'ai actuellement un projet SVN que j'aimerais brancher dans une arborescence de ce style :

• Projet
  
  • Trunk
  • Branches
    
    • Version 1.1
    • Version 1.2

Dans le trunk se trouve la version du projet qui va en Production, et dans branches, deux versions du projet pour deux axes de développements différents.

J'aimerais pouvoir pour chaque branche comiter des fichiers vers la version trunk afin de faire la mise en production. Dans l'idéal , il faudrait que pour chaque branche, une fois une partie du développement terminé, on fait nos tests puis si c'est concluant, on comite ces fichiers vers le trunk qui fait la mise en Prod.

J'ai compris la partie théorique, à savoir faire des branches puis merger une branche avec le trunk pour fusionner les fichiers.

Mais concrètement, je n'arrive pas à le mettre en pratique sur et uniquement sur Eclipse. J'ai créé des branches, essayer les differents switch with another branch ou le merge, mais j'arrive pas à avoir deux branches distinctes qui comitent et updatent chacune de leur coté, et puissent merger avec le trunk quand c'est nécessaire.

Auriez vous un tutoriel complet étape par étape ( la plupart sont avec les lignes de commandes, mais je n'ai pas accès au serveur SVN !! ) pour créer ce genre d'arborescence sur Eclipse ?

Merci de votre aide

[Laurent.B]

Bonjour,

Alors premièrement, tu n'as pas besoin d'être sur le serveur pour exécuter des commandes SVN, il te suffit d'avoir un client SVN. Subclipse en est un et se plug à Eclipse. Si tu veux un client en ligne de commande, tu as le choix a priori, mais par exemple, sous Windows, je te recommande Tortoise.
Personnellement, en plus de Subclipse, j'installe toujours Tortoise car les fonctionnalités de ces deux clients sont très similaires mais néanmoins complémentaires.

Deuxièmement, je n'ai pas bien saisi comment tu organises tes projets sous Eclipse mais lorsque tu as plusieurs versions d'un même projet à gérer, il faut avoir autant de projets que de versions. Donc l'erreur que l'on peut faire au début c'est de croire que d'une version (d'une branche par exemple), on peut commiter sur le trunk directement. Selon ton explication, cela ne semble pourtant pas être ton cas...

Quoi qu'il en soit, que tes projets soient des projets Eclipse ou non, si tu as une version trunk et deux versions branch, alors tu dois avoir la structure locale suivante :

• ProjetX (trunk/projetX)
• ProjetX_xyz (branch/projetX_xyz)
• ProjetX_mno (branch/projetX_mno)

(les noms n'ont pas d'importance particulière, c'est à toi de les nommer intelligemment afin de t'y retrouver)

Les répertoires locaux de tes projets peuvent se trouver à n'importe quel endroit sur ton disque (avec Tortoise c'est plus simple à voir), et sous Eclipse tu as tes 3 projets (ouverts ou non en même temps).

En ce qui concerne la fonction de switch, à mon sens, c'est plus à utiliser lorsque tu ne veux avoir qu'une seule version à la fois et que tu bascules d'une branche à l'autre (trunk compris) mais à partir du moment où tu as tes trois versions sous Eclipse, son utilité est assez limité car il suffit de supprimer un projet de Eclipse pour s'en débarrasser. Et de toute manière, les différentes versions sont toujours sur le repository, si jamais tu veux réimporter une branche...

Donc l'idée est de faire les dév et modif dans la branche ou le trunk et lorsque tu veux fusionner une branche avec le trunk, tu t'assures que tous les fichiers versionnés de ta branche sont tous commités sur le repository, que ton trunk est également commité, donc rien en attente de commit dans l'un ou l'autre et ensuite, tu fais ta fusion à partir du trunk (local à ta machine), en indiquant la branche concernée sur le repository.
Une fois que tu as fais ta fusion dans le projet trunk local, que tu as résolu les éventuels conflits, tu commites le tout.

Voilà, bon c'est sûr que ça n'a rien de trivial et il vaut peut-être mieux se faire la main avec des projets bidons afin d'éviter de faire des bêtises ou de perdre l'intérêt d'un tel système

Tu vois le truc ?

[fflash]

Bonjour,

Je me permets de déterrer ce poste car j'ai un projet à gérer et l'utilisation des branches dans svn pourrait répondre à mon besoin. Cependant je ne suis pas sur que ce soit la meilleur méthode.

Le projet est pour le moment composé d'un trunk sur lequel travaille deux équipes éloignées et indépendantes. Une première équipe s'occupe de développer la base et les fonctionnalités du logiciel, alors que la deuxième équipe développe une fonctionnalité particulière et doit être au maximum a jour avec ce que développe la première équipe. (sinon l'équipe 2 va développer son travail sur du vieux code et le merge sera douloureux, problème actuel)

Je voudrais donc utiliser un trunk, une branche 1 pour l'équipe 1 et une branche 2 pour l'équipe 2.

La deuxième équipe à besoin de faire beaucoup de test et modifier pas mal de chose avant de pouvoir valider et comiter son travail.

La gestion en branches permettrait pour la première équipe de développer ses fonctionnalités et une fois valider faire un merge vers le trunk.
Pour la seconde équipe d'avoir une branche dédiée pour faire ses tests et "salir" le code jusqu'à validation et merger vers le trunk.

Cependant, cela nécessite à chaque merge de l'équipe 1 vers le trunk un merge du trunk vers l'équipe 2 afin de maintenir la branche de l'équipe 2 au maximum à jour. Pareil lorsque l'équipe 2 merge vers le trunk, l'équipe 1 doit se mettre a jour.

Est-ce bien de cette façon qu'il faut organiser le svn et régir les merges ou bien il y a une manière plus appropriée d'organiser tout ça?

[Laurent.B]

Bonjour,

Ta logique semble assez cohérente mais personnellement, dans ton cas, je ne vois pas l'intérêt d'avoir une branche par équipe. A mon sens, une seule branche pour l'équipe 2 suffirait et le trunk reste la branche de l'équipe 1.

A moins d'avoir oublié de préciser certaines contraintes, la branche de l'équipe 1 ne semble pas nécessaire.

[fflash]

En effet ça simple plus simple de cette façon la.
Merci pour ton aide.