Conservation de bibliothèques tierces dans le cadre d'un projet Mercurial: sous-dépôts ou non?

Question

Nous développons un projet à code source fermé, versionné avec Mercurial. Nous utilisons deux bibliothèques dans notre projet:

• Une de ces bibliothèques est en cours de développement par un tiers. Ils utilisent git, et nous sortons habituellement de leur repo une fois par semaine pour obtenir les derniers changements.

• L'autre bibliothèque est en cours de développement et est en cours de développement. Il doit vivre dans son propre dépôt public, car il est sous licence LGPL. (Il est une fourchette d'un composant LGPL tiers, porté à notre plate-forme)

Alors ma question est la suivante: Comment organiser la source pour faire en sorte que:

1. Un développeur de notre L'équipe devrait pouvoir obtenir toute la source (projet principal + bibliothèques) avec une seule commande "clone"

2. Nous devrions être en mesure de tirer facilement les dernières modifications des bibliothèques, même si l'une d'entre elles est gérée par git

Faut-il utiliser la fonctionnalité de sous-dépôt mercurial, avec hg-git pour accéder à la bibliothèque sous git? Est-il bien supporté par TortoiseHg et BitBucket? (avantages: facile à tirer les changements de bibliothèque/inconvénients: ça marche bien?)

Ou devrions-nous garder seulement les instantanés des bibliothèques de notre projet? (donc, quand il y a de nouveaux changements en amont dans les bibliothèques, nous les amenons dans un endroit séparé, puis nous copions toute la source dans notre projet (avantages: ça marche/ça marche: la douleur dans le cul, surtout pour la bibliothèque qui est en cours de développement par nous-mêmes, qui est sujet à beaucoup de changements quotidiens)

Answer 1

Oui, utilisez le subrepo avec hg-git C'est facile, bien supporté et efficace Votre fichier .hgsubstate inclura des pointeurs vers des snapshots des sous-éléments , et ce fichier est contrôlé, donc à tout moment, vous serez capable de répondre à la question: quelle est la version de la bibliothèque X.

Alternativement, vous pouvez utiliser un gestionnaire de dépendances comme ivy ou maven selon votre langue, mais n'incluez pas leurs bibliothèques dans votre repo si vous pouvez l'éviter. Les pointeurs vers les versions de leur code sont meilleurs et un gestionnaire de dépendance ou des sous-états sont les moyens les plus propres de le faire.