2010-08-08 6 views
18

Existe-t-il un moyen de cloner un repo contenant des sous-états, mais sans que Mercurial ne retire tous les sous-états?Mercurial `hg clone` mais ignorant tous les sous-états?

Il semble que si hg clone -U peut être utilisé pour obtenir un clone vide d'un repo, il n'y a rien qui puisse convaincre hg update de ne pas commencer en tirant tous les sous-états.

Je tiens à souligner qu'il est crucial de conserver la possibilité de synchroniser facilement à la révision de la tête après la création d'un tel clone.

Répondre

5

Cette réponse peut ajouter que la question nécessaire, mais fournit des notes précieuses sur le travail avec Mercurial lorsque vous ne pouvez pas mettre à jour à faire un mauvais chemin ou subrepository révision.

Étape 1: Clone du référentiel sans mises à jour

hg clone --noupdate source_repository destination_repository 

Étape 2: utiliser Revenir en arrière pour obtenir les bons fichiers

hg revert --all --rev revision_number --exclude subrepo_1 --exclude subrepo_2 ... 

À ce stade, vous avez un nouveau changeset; vous devrez peut-être vous assurer que la révision parente est correcte. Quand je l'ai fait, le parent de mon nouveau changeset était changeset 0. Pour résoudre ce problème, j'ai dû définir le parent changeset ET passer les branches (puisque mon changeset était sur une branche différente).

Étape 3: Changer le parent du courant change

hg debugsetparents revision_number 
hg branch branch_name 

Cela devrait le faire.

+2

Après l'étape 3, 'hg status' affiche toujours tous les fichiers en tant qu'ajouts en attente. L'exécution de 'hg debugrebuildstate -r tip' corrige cela. –

3

Si vous avez une sous-requête, un répertoire de travail doit inclure une version de ce sous-objet. Cette version peut être une ancienne révision fixe si elle est spécifiée, ou la pointe si ce n'est pas le cas.

Vous ne pouvez pas mettre à jour votre repo sans obtenir les subrepos; Si vous avez un répertoire de travail complet sans eux, vous ne devriez pas utiliser de sous-dépôts - utilisez plutôt des dépôts externes.

Si vos subrepos sont chevillés contre une certaine version à distance, puis mises à jour après la première ne déclenchera pas une mise à jour subrepo - ils sont déjà à jour. Mais pour la création initiale du répertoire de travail, vous devrez faire un tirage à distance.

Vous pouvez tromper Mercurial par munging le fichier hgsubstate. Mais en réalité, votre modèle et le modèle conceptuel diffèrent, de sorte que vous n'êtes probablement pas un bon candidat pour les sous-dépôts si cela vous préoccupe.

edit: Si vous vous trouvez en train de cloner puis de mettre à jour plusieurs fois l'astuce, essayez plutôt d'utiliser des branches locales ou mq. De cette façon, il suffit de faire le clone initial une fois.

+0

Ils semblent un bon match la plupart du temps. C'est juste que les sous-dépôts sont importants, et la meilleure façon de différencier le "serveur" officiel que j'ai trouvé est de garder une caisse locale propre. Les sous-états ajoutent une tonne de frais généraux à cette approche. –

+0

@romkyns: si vous voulez juste garder une trace de ce que vous avez changé, utilisez 'hg out' (ou' hg diff' pour les modifications non validées). Ou vous pouvez simplement créer le clone "clean" une fois, et utiliser occasionnellement "hg pull -u'" pour le garder à jour ... – Borealid

+0

Merci, je suppose que je vais juste devoir tolérer un tas de copies supplémentaires de ces énormes sous-états. Je trouve 'hg diff' sous-optimal pour la révision du code et j'utilise à la place un diff basé sur une interface graphique externe. –

4

trouvé un moyen aki. Il exige toujours que tous les sous-enregistrements soient extraits une fois, mais ils peuvent ensuite être supprimés.

  1. Cloner le lot entier, y compris les sous-dépôts. Pas moyen de contourner cela.
  2. subrepos Supprimer
  3. hg remove .hgsub

j'ai essayé de convaincre Mercurial à hg remove .hgsub avant que les subrepos sont clonés, mais le mieux que je suis arrivé est not removing .hgsub: file is untracked.

+6

C'est dommage. –

+6

Cette solution n'aide vraiment pas si votre subrepo externe est inaccessible pour une raison quelconque. Une discussion sur ignorer les sous-déclarations [ici] (http://mercurial.selenic.com/bts/issue2520). –

13

Cela devrait faire ce que vous voulez:

REM Take a new clone, but do not update working directory 
hg clone --noupdate %REPO_PATH% %DESTINATION% 

REM Update working directory but exclude the certain subprojects 
hg revert --all --rev %BRANCH% --exclude %SUBREPO_PATH_1% --exclude %SUBREPO_PATH_2% 
Questions connexes