Maintenir les branches et les tags dans un projet multi-modules qui utilise mercurial

Question

Je travaille sur une application avec de nombreux modules ayant chacun leur propre dépôt mercurial.

J'ai d'abord pensé que c'était une bonne chose d'avoir les modules dans des dépôts individuels, mais après quelques versions, j'ai senti que quelque chose n'allait pas. C'est vraiment pénible de créer les branches et les tags dans tous les modules.

La plupart des modules, si ce n'est tous, suivent un cycle de publication similaire.

Dois-je aller de l'avant et utiliser un dépôt unique pour tous les modules ? Ou y a-t-il une meilleure solution ?

Answer 1

Un référentiel unique pour tous les modules signifie qu'ils sont étroitement liés dans leur cycle de développement :

• toute branche s'applique à tous les modules (c'est ce que vous voulez)
• toute balise s'applique à tous les modules (ce qui n'est peut-être pas ce que vous voulez)

Si la "v1.2" de votre logiciel a une signification pour chacun de vos modules, alors oui, les avoir tous dans un seul repo est utile.

Si certains modules sont à la version 2.4 alors qu'un autre est à la version 3.6, et un autre à la version 4.5, et..., il est préférable d'avoir des modules indépendants déclarés en tant que sous-répositions.

---

Lasse V. Karlsen commentaires :

si vous partagez des éléments, tels que des composants et des bibliothèques générales, ils doivent être placés dans leurs propres dépôts

Ce qui est exact, puisque le cycle de développement de ces composants et des bibliothèques du cadre général n'a rien à voir avec celui du programme principal.

Mais le PO ajoute :

Nous disposons de deux séries de modules :

• un ensemble de modules de base qui peuvent être réutilisés dans de nombreuses applications et
• un autre ensemble de modules pour l'application concernée

Ainsi, certains de ces modules (l'"ensemble des modules de base") peuvent être conservés en tant que sous-répôts (dépôts indépendants référencés par le dépôt parent et le projet principal).

Les autres peuvent être fusionnés directement dans le repo parent (un peu comme la commande stratégie de fusion des sous-arbres git ) avec l'astuce Hg que vous mentionnez : " Combiner des référentiels "

Answer 2

Si tous ces modules appartiennent à un seul projet, ils devraient avoir un seul dépôt. Le code des modules peut être regroupé dans des répertoires au sein d'un même dépôt.

[Edit : basé sur les commentaires]

La structure se présente comme suit :

1. Vous disposez de modules de base ~ Plate-forme
2. Diverses autres applications / modules qui utilisent les modules de base.

Dans ce cas, la plate-forme ou le module central peut se développer à une vitesse différente de celle des modules d'application. Il est préférable de les séparer dans des référentiels distincts. Au départ, il semble séduisant que les deux suivent un cycle de publication similaire, mais dans tout développement de plateforme ou d'application typique, ils se développent indépendamment et de manière désynchronisée. C'est du moins ce que j'ai constaté.

P1 -------P2 ------P3 ------p4

A1------A2--------------A3--------- (A1, A2, A3 utilize platform P1, P2, P3..)

B1--------B2----------B3---------   (B1, B2, B3 utilize platform P1, P2, P3..)

A3------------------B3--------------

Answer 3

Il est vraiment pénible de créer les branches et les étiquettes dans tous les modules.

Parce que c'est vraiment pas du tout nécessaire ("dans tous les modules").

Si vous utilisez Subrepo (ou mieux, GuestRepo - créée exactement pour votre cas d'utilisation et pour compenser les inconvénients de certaines subrepo) et que votre produit est une "SuperRepo", qui ne contient que des sub|guestrepos liées, alors.. :

Pour chaque jeu de modifications dans la Superrepo, l'état de toutes les child-repos est le suivant connu et prédéfini (chaque définition contient le changeset-ID du repo étranger). Ainsi :

• Ensuite vous marquez, vous ne pouvez (avez) que marquer la Superrepo - les changeset marqués auront toutes les relations (immuables).
• Puis vous branchez, vous pouvez ne pas ramifier les sous-modules du tout, ou brancher le sous-module quand il est nécessaire pour le développement, pas pour la politique (résultat final dans tous les cas pour SuperRepo - changeset ID dans le lien vers cette sous-répo) : la branche "Release N" ne nécessite pas la même branche sur les sous-modules, seulement un peu plus de travail manuel dans Superrepo

Du point de vue de la flexibilité et de la facilité de gestion, je préfère toujours un repo séparé pour chaque module de bas niveau (objet autonome, sans dépendances externes) et GuestRepo pour collecter les modules dans le(s) produit(s) et gérer le produit dans son cycle de vie - je ne vois pas de "cauchemar de branchement ou d'étiquetage" ici.