Mercurial "branches de fournisseur" de dépôts externes?

Question

Je veux stocker un projet dans Mercurial qui contient du code externe (que je peux modifier) ​​provenant de dépôts Git et SVN. Dans SVN, je voudrais résoudre ce problème avec vendor branches et copier le code autour, mais j'ai compris cela dans Mercurial it's better to have different repositories for different projects, et tirer entre eux si nécessaire.

La mise en page du projet sera comme ceci:

 
- externalLibraryA [comes from a SVN repo] 
    - ...with some extra files from me 
- externalLibraryB [comes from a SVN repo] 
    - ...with some extra files from me 
    - externalPluginForExternalLibraryB [comes from a Git repo] 

Dans Subversion je créerais vendor dir et trunk dir, copiez toutes les bibliothèques externes d'abord dans vendor, puis au bon endroit dans trunk. (Je pense) Je peux le faire dans Mercurial aussi, avec subrepositories, mais est-ce la meilleure façon de le faire?

J'ai essayé de configurer différents référentiels pour les bibliothèques externes, mais il semble que je ne puisse pas tirer le externalLibraryARepo dans le répertoire externalLibraryA de mon référentiel principal? Il va dans le répertoire principal, ce qui n'est pas ce que je veux. Je peux également créer un référentiel miroir Mercurial et l'inclure en tant que sous-référentiel dans mon référentiel principal, mais les changements dans ce sous-répertoire vont dans le référentiel miroir, alors que je veux qu'ils restent dans le référentiel principal.

Answer 1

Je stockerais probablement ceci dans un seul dépôt - notez que dans le lien que vous donnez, ils utilisent leur système de construction à la fin pour rassembler la sortie binaire des différents repos. Je ne suis pas clair sur leur justification là.

Si le problème sous-jacent que vous essayez de résoudre est de savoir comment mettre à jour les externes de manière propre, j'utiliserais probablement anonymous branching pour cela.

I.e. ajoutez la lib externe à votre projet et vos modifications. Assurez-vous que cela fonctionne. Tag avec ExternalA-v1.0. Hack loin sur votre projet actuel. Maintenant, ExternalA, Inc. a une nouvelle version de leur contenu. Mettez à jour votre repo à l'étiquette ExternalA-v1.0. Importez leur nouvelle version et appliquez vos modifications par-dessus. Commettre. Maintenant, vous avez deux têtes: une avec la dernière version de votre code (qui fonctionne avec ExternalA-v1.0) et une avec la dernière version d'ExternalA (qui ne fonctionne pas avec votre code, peut-être). Alors vous fusionnez et réconciliez les deux. Marquer à nouveau, maintenant avec ExternalA-v2.0. Répétez au besoin.

Vous pouvez toujours conserver vos données externes dans des référentiels distincts, mais je suppose que le projet qui les utilise n'a pas besoin d'être à jour avec les modifications apportées à tout moment - il semble que l'ensemble des branches des fournisseurs doit avoir un certain point d'isolement entre la personne à charge et les personnes à charge. Bien sûr, déplacer les changements du projet externalA vers le projet qui utilise cela sera alors une affaire manuelle (enfin, une copie, comme dans SVN).

Answer 2

Cela dépend si votre code fournisseur va être personnalisé par votre équipe ou non. Nos équipes ont eu beaucoup de succès en maintenant une branche nommée "fournisseur" sur des dépôts avec nos propres personnalisations sur les branches nommées par le nom du projet. Ce code fournisseur est alors facilement inclus dans un projet en tant que sous-répertoire. Mise en garde de cette approche: si un développement actif est en cours dans le sous-dépôt, mieux vaut l'éditer directement en tant que clone séparé, sinon il est nécessaire de porter une attention particulière au référentiel de niveau supérieur. Par inadvertance, votre .hgsubstate ne sera pas redirigé vers la mauvaise révision et cassera votre build. Attention aux fusions du référentiel de niveau supérieur (votre projet) entre les versions qui pointent vers différentes branches nommées de votre sous-dépôt, car cela peut entraîner une fusion entre les branches "fournisseur" et "projet" dans le sous-répertoire comme il récursive, ce qui peut ne pas être souhaitable.Notez que cette fonctionnalité peut également changer dans le futur, étant donné que des discussions «chaleureuses» ont eu lieu ces derniers mois sur les listes de diffusion de mercurial-devel concernant l'avenir de la récursivité des sous-dépôts.

modifier: Je viens de voir cette discussion dans les liens connexes ainsi, qui semble pertinente: https://stackoverflow.com/a/3998791/1186771