mise en place de sous-dépôts mercurial / kiln sur osx
-
28-10-2019 - |
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.
La solution
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.