Quand un projet multi-modules doit-il être divisé en arborescences de référentiels distinctes ?

Question

Actuellement, nous avons un projet avec une disposition de référentiel Subversion standard de :

./tronc
./branches
./Mots clés

Cependant, à mesure que nous avançons sur la voie d'OSGi et d'un projet modulaire, nous nous sommes retrouvés avec :

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

La « build » est encore assez monolithique dans la mesure où elle construit tous les modules dans l'ordre, même si je commence à me demander si nous devrions refactoriser la build/le référentiel en quelque chose qui ressemble davantage à :

./bundle/main/tronc
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea-1.0.0

Dans ce modèle, j'imaginerais que chaque module se construit lui-même et stocke son binaire dans un référentiel (maven, ivy ou un autre chemin du référentiel Subversion lui-même).

Existe-t-il des lignes directrices ou des « meilleures pratiques » concernant la configuration des projets une fois que l'on devient modulaire ?

Answer 1

Le livre Subversion contient deux sections à ce sujet :

• Disposition du référentiel
• Planification de l'organisation de votre référentiel

Un article de blog sur le sujet : "Disposition du référentiel Subversion"

La réponse courte, cependant :même si votre kilométrage varie (chaque situation est individuelle), votre /bundle/<project>/(trunk|tags|branches) Ce système est plutôt courant et fonctionnera probablement bien pour vous.

Answer 2

Cela dépend beaucoup de vos préférences personnelles, mais je trouve la structure suivante adaptée aux grands projets composés de nombreux modules :

branches
  project-name
    module1
      branch-name
    module2   
      possibly-another-branch-name
    branch-name-on-a-higher-level-including-both-modules
      module1
      module2
tags
  ... (same as branches)
trunk
  project-name
    module1
    module2

J'ai également souvent utilisé cette structure dans de grands référentiels contenant de nombreux projets, car le fait de conserver tous les projets dans le même référentiel facilite les références croisées des projets et le partage de code entre eux (avec historique).

J'aime utiliser la structure avec les dossiers de tronc racine, de balises et de branches dès le début car, d'après mon expérience (avec de grands référentiels contenant de nombreux projets), de nombreux sous-projets et modules n'auront jamais de balises ou de branches séparées, il n'est donc pas nécessaire de le faire. créez la structure de dossiers pour eux.Cela permet également aux développeurs de vérifier plus facilement l'intégralité du tronc du référentiel et de ne pas obtenir toutes les balises et branches (dont ils n'ont pas besoin la plupart du temps).

Je suppose que c'est une question de projet ou de politique d'entreprise.Si vous disposez d'un référentiel pour chaque projet ou si un développeur donné ne travaillera probablement que sur un seul projet dans le référentiel à la fois, le tronc enraciné n'aura peut-être pas autant de sens.

Answer 3

Juste mes deux cents...

Je veux juste souligner le commentaire dans la documentation SVN (déjà cité dans une autre réponse, même fil) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

L'extrait fait référence à la structure suivante :/ tronc / calc / calendrier / feuille de calcul /… tags / calc / calendrier / feuille de calcul /… branches / calc / calendrier / feuille de calcul /

"Il n'y a rien de particulièrement incorrect dans une telle mise en page, mais elle peut sembler aussi intuitive ou non pour vos utilisateurs.En particulier dans les situations de grande envergure et multi-projets avec de nombreux utilisateurs, ces utilisateurs peuvent avoir tendance à ne connaître qu'un ou deux des projets du référentiel.Mais les projets en tant que succursales ont tendance à minimiser l'individualité du projet et à se concentrer sur l'ensemble des projets en tant qu'entité unique.C'est cependant un problème de société.Nous apprécions notre arrangement initialement suggéré pour des raisons purement pratiques : il est plus facile de poser des questions (ou de modifier ou de migrer ailleurs) sur l'intégralité de l'historique d'un seul projet lorsqu'il existe un seul chemin de dépôt qui contient l'intégralité de l'historique : passé, présent, balisé et ramifié - pour ce projet et ce projet seul.

Pour ma part, j'ai tendance à être tout à fait d'accord avec cela et je préfère la présentation suivante :/ utils / calc / trunk / tags / branches / calendar / trunk / tags / branches /… toffet / feuille de calcul / tronc / tags / branches /

La raison est simplement qu'il n'est pas pratique de baliser un ensemble de projets complet alors que l'on souhaite baliser uniquement un sous-ensemble spécifique.

Prenons un exemple :Si le projet-1 dépend de moduleA v1.1 et moduleB v2.3, je ne veux pas que le nouveau moduleA v2.x apparaisse dans les balises.En fait, en revenant quelques jours/semaines/mois plus tard sur cette version balisée, je serais obligé d'ouvrir le descripteur de bundle dans la version balisée du projet-1 pour lire la version de moduleA réellement requise.

De plus, si je dois faire une sauvegarde spécifique des sources de cette version sur un CD, je souhaite simplement exporter cette balise sans télécharger des centaines de mégaoctets de données sans rapport.

C'était juste mes deux cents.

Answer 4

J'ai répondu à une question similaire dans un StackOverflow Question sur la structure de contrôle de version.En fait, cela convient encore mieux ici puisque nous effectuons un développement OSGi intensif et que nous disposons de nombreux bundles.Je dois faire écho aux commentaires d'Anders Sandvig :conservez trunk/tags/branches au niveau racine puisque vous ne brancherez qu’un ensemble limité de modules.Cela n’interfère pas non plus avec la construction de modules individuellement.

Je ne copierai pas la réponse que j'ai faite auparavant mais elle est tout à fait pertinente pour cette question.