mise en place de sous-dépôts mercurial / kiln sur osx

Question

J'ai essayé de suivre les instructions de la réponse à cette question , en utilisant le four.

Je voudrais pouvoir organiser les choses comme suit:

• /somepath/thirdparty est mappé vers un référentiel de four "tiers" et contient un code assorti
• /somepath/common correspond à un référentiel de four "commun" et contient du code partagé que j'ai écrit

et

• /somepath/project1 mappe au dépôt de four "project1"
• /somepath/project1/thirdparty correspond à la succursale du tiers ci-dessus
• /somepath/project1/common correspond à la branche commune ci-dessus

et

• /somepath/project2 mappe au dépôt de four "project1"
• /somepath/project2/thirdparty mappe vers une autre branche du tiers ci-dessus
• /somepath/project2/common correspond à une autre branche du commun ci-dessus

J'ai trouvé que lorsque j'ai créé le fichier .hgsub comme indiqué et ajouté / poussé vers Kiln, je ne pouvais plus afficher les fichiers Kiln dans la visionneuse de fichiers Web Kiln - il affichait un message obscur à propos de la "surchauffe" du four: - ) De plus, bien qu'il ait créé automatiquement les sous-dossiers au bon endroit, ils n'étaient pas remplis de fichiers, (peut-être parce que l'extraction a échoué).

Quelqu'un a déjà essayé quelque chose comme ça, en utilisant Kiln?

Comme j'ai l'intention de développer un certain nombre d'applications en utilisant le code commun (et éventuellement de publier la bibliothèque en open source), j'aimerais qu'elle soit gérée dans des référentiels discrets. Cependant, comme certains projets sont destinés aux clients finaux, je dois être en mesure de leur donner un référentiel unique qui inclut les éléments décrits ci-dessus.

Answer 1

Kiln ne prend actuellement pas en charge les sous-dépôts qui utilisent des URL imbriquées sur le serveur . Cela signifie que vous ne pouvez pas faire fonctionner les deux URL suivantes:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project1/thirdparty

Vous devez donc configurer Kiln de manière à disposer de quatre référentiels sur le serveur:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project2
http://server/kiln/somepath/thirdparty
http://server/kiln/somepath/common

C'est facile - juste quatre dépôts normaux. Puis clonez "project" et créez le fichier .hgsub avec:

thirdparty = http://server/kiln/somepath/thirdparty
common = http://server/kiln/somepath/common

Lorsque vous repoussez cela vers Kiln, il remarquera et affichera des liens pour les sous-référentiels. Cependant, les sous-référentiels ne finiront pas par être imbriqués sur le serveur. Il n'y aura donc pas de chemin project1/thirdparty sur le serveur.

Il est également loin d'être clair que vous souhaitiez cela. Lorsque vous avez plusieurs projets qui collaborent et utilisent une base de code commune, alors vous voulez que "project1" et "project2" obtiennent les modifications de l'autre dans cette base de code commune. Il est donc très utile que le subrepo common dans les deux projets pousse et tire depuis http://server/kiln/somepath/common.

Dans Mercurial, nous vous recommandons normalement d'utiliser des chemins de la forme common = common dans le fichier .hgsub. Cela signifie que le serveur doit prendre en charge les référentiels imbriqués. Lorsque Kiln ne prend pas en charge les dépôts imbriqués, vous pouvez utiliser des chemins complets à la place.

Lorsque vous configurez initialement les sous-référentiels, n'oubliez pas que vous devez les mettre à jour manuellement. Donc, avec les URL ci-dessus, vous configurez "project1" en exécutant:

$ hg clone http://server/kiln/somepath/project1
$ echo "common =     http://server/kiln/somepath/common" > .hgsub
$ echo "thirdparty = http://server/kiln/somepath/thirdparty" > .hgsub
$ hg commit -m "Created subrepos"

Cela crée des sous-référentiels vides initiaux. Ils sont vides car vous n'avez pas indiqué à Mercurial le jeu de modifications dont vous avez besoin. Ceci est suivi dans .hgsubstate où vous trouverez:

0000000000000000000000000000000000000000 common
0000000000000000000000000000000000000000 thirdparty

Pour remplir les sous-référentiels que vous faites

$ cd common
$ hg pull --update
$ cd ../thirdparty
$ hg pull --update
$ cd ..
$ hg commit -m "Updated subrepos"

Ceci met à jour les lignes 000... dans .hgsubstate avec les ID de jeu de modifications de pointe actuels pour les deux sous-dépôts. Les futurs clones de "project1" remarqueront le fichier .hgsubstate et veilleront à mettre à jour les sous-dépôts avec la révision mentionnée ici.