Référentiels de succursales Mercurial avec SUBREPOS

Question

J'essaie de déterminer comment les gens utilisent des «dépôts de succursales» tout en utilisant des sous-dépôts.

Disons que je repo principal contenant un fichier de solution (.NET), et peuplée avec subrepos A, B, C:

/Main 
    - A 
    - B 
    - C 
    MainSolution.sln 

A, B et C, tout en étant partagé entre les autres « Main "repos, sont très étroitement intégrés dans le projet principal. Ainsi, une caractéristique majeure du dépôt principal nécessitera des modifications aux sous-rapports (c.-à-d., Ce sont des bibliothèques partagées, mais elles sont très activement développées).

Il est maintenant temps d'ajouter une fonctionnalité. Cette fonctionnalité est trop importante pour une personne, et le code devra donc être transmis au dépôt central pour que les autres puissent vous aider. Nous devrons également pouvoir revenir au dernier code "stable" avant le début du développement de fonctionnalités au cas où un correctif serait nécessaire. Je crois que j'ai deux options à ce stade: (1) créer une branche nommée dans le repo principal, ou (2) créer un nouveau clone de Main. Comme il y a des sous-récapitulatifs, ces deux options ont des répercussions qui ne sont généralement pas présentes.

Option 1) La création d'une branche nommée permettra, je présume, de modifier/valider les sous-états, mais seules les autres personnes qui ont également mis à jour cette branche dans leur clone de Main seront affectées. Le fichier hgsubstate est suivi. Cependant, les sous-dépôts auront une nouvelle tête, et donc (éventuellement) la caractéristique expérimentale finirait par être poussée au dépôt central. Est-ce que je comprends bien?

Option 2) Il y a de nombreux partisans du «ne pas utiliser les branches nommées, utiliser les dépôts de branches», qui sont littéralement des clones du dépôt principal, mais nommés différemment et existant sur le serveur central. C'est un peu attrayant pour moi, car il semble garder les choses séparées (et donc détaché du désastre en tant que collègues - et moi-même - nous apprenons encore Mercurial). Mais ce workflow semble complètement rompu lorsque des sous-dépôts sont impliqués, car la création d'un clone du repo principal ne crée pas de nouveaux clones séparés des sous-états. C'est un nouveau clone, mais il montre toujours les mêmes sous-rapports, et ainsi les changements qui leur seront apportés retrouveront leur place dans les sous-états! Je réalise que c'est par conception, et c'est l'une des choses vraiment cool (à moi) à propos de Mercurial. Mais comment diable les gens utilisent-ils ce workflow de dépôt de branche avec des sous-dépôts? Il est complètement inconcevable que, pour chaque fonctionnalité/expérience/version/quoi que ce soit, je vais créer un nouveau clone (sur le serveur central) du dépôt principal, ET créer des clones (sur le serveur central) des sous-états, ET modifier tous les chemins .hgrc/.hgsub pour pointer vers les bons repos centraux. À ce stade, j'essaie simplement de comprendre comment les gens travaillent sur un projet compliqué et utilisent des sous-dépôts avec des dépôts de succursales. Des pensées?

Answer 1

Je préfère les branches nommées pour les entités qui seront probablement fusionnées dans la branche par défaut. Il est beaucoup plus facile de changer de branche que de passer des repos.

Avec des branches nommées, vous n'avez jamais à vous soucier de pousser accidentellement votre branche de développement instable dans le repo stable. La branche nommée est déjà là, mais ne sera pas récupérée via une mise à jour à moins qu'un développeur ne le demande.

Answer 2

Vous avez également d'autres options. Vous pouvez utiliser des signets, par exemple. Depuis la version 1.9, les signets peuvent être poussés et extraits, ils ne sont plus seulement locaux. Puisque vous ne voulez pas qu'une branche de développement reste une branche nommée après que cette nouvelle fonctionnalité soit terminée, les signets sont souvent un meilleur choix pour ce genre de chose. J'ai tendance à utiliser des signets pour de nouveaux développements et à enregistrer de vraies branches pour les versions publiées.

Vous devez également savoir que les sous-dépôts n'ont pas de à partager entre plusieurs référentiels principaux de la manière que vous décrivez. Vous pouvez réellement avoir les sous-dépôts stockés dans un référentiel principal (par opposition à les avoir au même niveau que le repos principal, ou stockés dans un autre emplacement entièrement), ce qui les rendrait unique à chaque dépôt principal, sauf vous pouvez pousser et tirer des sous-dépôts dans d'autres repos principaux quand vous voulez partager ces changements. C'est comme ça que je le fais habituellement. Malheureusement, une grande partie de ce problème est difficile à expliquer sans un tableau blanc, alors faites-moi savoir si ce n'est pas clair.