sous-total mercurial à la révision actuelle d'une branche spécifique

Question

Je suis assez nouveau à mercurial, j'ai lu beaucoup de sujets sur ce sujet mais je ne peux toujours pas comprendre si je peux réaliser ce que j'essaye de faire . Fondamentalement, je serais intéressé par le clonage de la révision en cours d'une branche à partir d'un dépôt principal et de ses sous-états en une seule commande (agissant sur le repo principal). Je vais essayer de l'expliquer dans un instant. Disons que j'ai séparé mon code en modules (un seul module dans l'exemple ci-dessous). Je voudrais avoir chaque module dans son propre dépôt, et un maître repo (celui qui a le .hgsub) comme colle pour garder tous les sous-états en place. Le repo maître contient juste .hgsub et un script qui (1) hg archive chaque subrepo dans un répertoire prédéfini et (2) effectue une construction hors-source du code. Tout le développement, commettre, pousser, tirer, fusionner est fait dans les sous-états individuels.

# create a module (subrepo of the master) 
hg init subrepo 
cd subrepo/ 
echo "a file" > aFile.c 
echo "another file" > anotherFile.txt 
hg add 
hg ci -m "initial rev of subrepo" 

# create the main (master) repo & add the reference to subrepo 
cd ../ 
hg init main 
cd main 
hg clone ../subrepo subrepo 
echo subrepo = ../subrepo > .hgsub 
echo hg archive and out-of-source build > build.script 
hg add 
hg ci -m "initial rev of main repo" 

Jusqu'ici, tout va bien. Si je hg clone main je reçois la révision actuelle de la branche par défaut de subrepo, comme prévu. MAIS, imaginons maintenant que je suis prêt à expédier mon code dans une version: le 1.0.0. Je ferais comme suit.

# create the branch 1.0 to manage the bug fixes to 1.0.0 and furthers 
cd ../subrepo/ 
hg branch 1.0 
hg ci -m "creating the branch 1.0" 

# backstep to the main line to carry on the development of new features 
hg up default 
echo "working in the main line" > aNewFeature.c 
hg add 
hg ci -m "carrying on the development in the main line (a new feature)" 
hg glog 
@ changeset: 2:c499329c2729 
| tag:   tip 
| parent:  0:50d4522a99ea 
| user:  XXXX 
| date:  Tue Dec 07 16:13:28 2010 +0100 
| summary:  carrying on the development in the main line (a new feature) 
| 
| o changeset: 1:0a81043e6e8a 
|/ branch:  1.0 
| user:  XXXX 
| date:  Tue Dec 07 16:12:02 2010 +0100 
| summary:  creating the branch 1.0 
| 
o changeset: 0:50d4522a99ea 
    user:  XXXX 
    date:  Tue Dec 07 15:52:57 2010 +0100 
    summary:  initial rev of subrepo 

Et voici où les problèmes se produisent. Comment est-ce que je change le rapport principal pour obtenir la révision actuelle du défaut ou, finalement, la branche 1.0 de subrepo, quand j'effectue hg clone?

J'aurais dit que cela a fonctionné.

# replicate the branch structure also in the main repo 
cd ../main/ 
hg branch 1.0 
echo subrepo = ../subrepo -r 1.0 > .hgsub 
hg ci -m "adding -r 1.0 to .hgsub" 
hg up default 
echo subrepo = ../subrepo -r default > .hgsub 
hg ci -m "adding -r default to .hgsub" 
hg glog 
@ changeset: 2:f97c90a31a21 
| tag:   tip 
| parent:  0:1fd6b5d528b4 
| user:  XXXX 
| date:  Tue Dec 07 16:22:05 2010 +0100 
| summary:  adding -r default to .hgsub 
| 
| o changeset: 1:3d9ed2f8b026 
|/ branch:  1.0 
| user:  XXXX 
| date:  Tue Dec 07 16:21:32 2010 +0100 
| summary:  adding -r 1.0 to .hgsub 
| 
o changeset: 0:1fd6b5d528b4 
    user:  XXXX 
    date:  Tue Dec 07 15:55:53 2010 +0100 
    summary:  initial rev of main repo 

Mais quand je hg clone la pension principale, je reçois

cd /a/directory 
hg clone /path/to/main -r 1.0 main 
requesting all changes 
adding changesets 
adding manifests 
adding file changes 
added 2 changesets with 3 changes to 2 files 
updating to branch 1.0 
pulling subrepo subrepo 
abort: HTTP Error 404: Not Found 

Est-il possible d'obtenir ce que je veux faire?

Merci.

Mise à jour rapide: juste une minute après avoir posté la question, j'ai trouvé un answer que je n'avais jamais vu auparavant. Là-bas, il est suggéré d'utiliser la syntaxe suivante

http://[user[:pass]@]host[:port]/[path][#revision] 

en utilisant #branchname en place de #revision. Ainsi, dans mon exemple, ce qui suit devrait fonctionner (pour la branche 1.0):

echo subrepo = ../subrepo#1.0 > .hgsub 

Mais quand je hg clone le repo maître-je obtenir:

pulling subrepo subrepo 
abort: unsupported URL component: "1.0" 
Exception AttributeError: "'httprepository' object has no attribute 'urlopener'" in <bound method httprepository.__del__ of <mercurial.httprepo.httprepository object at 0x871332c>> ignored 

Je travaille sur Ubuntu 10.04, mercurial 1.4.3-1. Suggestions?

- Dylan

Answer 1

Cette ligne est faux:

echo subrepo = ../subrepo -r default > .hgsub 

Vous ne pouvez pas ajouter des options supplémentaires pour l'opération de clonage dans le fichier .hgsub.Il est également faux de faire

 
echo subrepo = ../subrepo#1.0 > .hgsub 

Le fichier .hgsub a la structure:

subrepo-mount-point = subrepo-source-URL 

et c'est tout. Mercurial va alors sortir et utiliser le subrepo-source-URL pour faire un clone du sous-scénario et placer le clone subrepo au subrepo-mount-point à l'intérieur du repo externe.

La prochaine question est de savoir quelle révision du subrepo Mercurial devrait vous commander: la révision mentionnée dans le fichier .hgsubstate. Ce fichier a la structure

subrepo-revision-ID subrepo-mount-point 

où le subrepo-revision-ID est un hachage pour changeset subrepos Mercurial. Vous mettez à jour ce fichier en faisant

cd main/subrepo 
hg update 1.0 
cd .. 
hg commit -m 'Updated subrepo in main' 

Chaque fois que vous faites une livraison en un référentiel externe, sont écrits la révision exacte de tous les subrepos dans le fichier .hgsubstate dans le référentiel externe. C'est ce qui fait fonctionner le contrôle de version: quand vous faites hg update dans le dépôt externe, le fichier .hgsubstate change et Mercurial s'assurera de vérifier les versions correspondantes des sous-dépôts.

Je pense que vous essayez de créer un référentiel parapluie qui suit automatiquement une branche donnée pour un ensemble de sous-états. Vous ne pouvez pas le faire avec Mercurial: il insiste sur le fait que lorsque vous clonez le référentiel principal, vous obtiendrez une copie de travail contenant des sous-états dans un état connu, à savoir l'état validé dans le référentiel principal.

Si vous installez mon onsub extension, vous pouvez mettre à jour et valider toutes les subrepos comme celui-ci:

hg onsub hg update 
# run test! 
hg commit -m 'Updated all subrepos to their tip' 

Vous pouvez ensuite créer cette révision et l'envoyer à vos clients - s'ils reviennent avec une erreur et un hash de modification pour le référentiel principal, alors vous savez que vous pouvez recréer exactement la construction. Ce ne serait pas le cas si Mercurial n'avait pas enregistré les états de sous-dépôt dans le fichier .hgsubstate.