Comment devrais-je gérer la "restauration" d'une branche effectuée avec des signets dans mercurial?

Question

J'ai un projet open source sur bitbucket. Récemment, j'ai travaillé sur une branche expérimentale dont (pour une raison ou pour une autre) je n'ai pas fait de véritable branche. Au lieu de cela, j'ai utilisé des signets.

donc j'ai fait deux signets à la même révision

• essai --Le nouveau code, je travaillais sur qui devrait maintenant être abandonnée (en raison d'une panne d'expérience)
• principale - le code ancienne écurie cela fonctionne

J'ai travaillé dans le test. J'ai également poussé du test à mon serveur, qui a fini par basculer la balise tip vers le nouveau code instable, alors que j'aurais préféré rester à la main. Je suis "revenu" au signet principal en faisant hg update main puis en effectuant un changement insignifiant. Donc, j'ai poussé cela avec hg push -f et maintenant mon contrôle de source est "correct" sur le serveur.

Je sais qu'il devrait y avoir une façon plus propre de «changer» de branche. Que devrais-je faire à l'avenir pour ce genre d'opération?

Answer 1

Je ne comprends pas vraiment votre question, puisque vous changez de branche (sans guillemets), même si ce ne sont pas des branches nommées, ce sont toujours des branches lorsque vous utilisez des signets. L'erreur que vous avez commise était une erreur honnête et je ne vois pas comment Mercurial pourrait vous protéger contre les signets (en marquant le même rev avec différents signets et en vous engageant avec le mauvais). Ce que je peux vous dire est bien comment faire ramification locale privée avec Mercurial, et de cette façon vous pouvez éviter d'avoir les conséquences que vous venez d'avoir:

Vous utilisez les branches nommées et phases

Mercurial Phases sont vraiment doux, laissez-moi les expliquer très rapidement. Vous pouvez marquer les révisions de trois états spéciaux appelés phases, à savoir: secret, brouillon et public.

1. secret: Ne pas être poussé. Peut être modifié grâce à l'édition de l'historique.
2. brouillon: Poussé. Peut être modifié grâce à l'édition de l'historique. C'est l'état par défaut de toute révision.
3. public: être poussé. Émettra un avertissement lorsque vous utiliserez des extensions d'édition d'historique (strip, rebase, histedit, ...).

Comme mentionné précédemment, toutes les révisions locales sont projet par défaut, lorsque vous les poussez, ils deviennent publique. Vous pouvez utiliser la commande hg phase pour marquer les révisions d'une phase particulière, mais si vous passez de # 3 à # 2, ou de # 2 à # 1 (selon la numérotation précédente), vous avez besoin de l'argument -f pour forcer le changement, c'est:

secret -> projet -> publique

pour aller à gauche, vous devez utiliser --force ou -f.

Voici ce que vous faites:

hg branch experiment 
hg commit -m "Opening experimental branch" //say this creates revision 123 
hg phase -sf tip       //s is for secret, f is for force 
//... hack hack hack 
hg commit -m "Uh oh screwed up here" 
hg push         //no secret revisions are pushed 

Maintenant, vous pouvez simplement abandonner cette branche et le laisser comme cela, il ne sera pas toujours se poussé. Oubliez-le et fermez-le pour qu'il ne vous dérange pas lorsque vous dressez la liste de vos succursales. Il ne sera pas poussé, il ne sera pas listé, donc ne vous inquiétez pas à ce sujet.

Cependant, si vous avez le TOC, bande juste (hg strip) la branche au commit où la succursale a été ouverte, et il est parti:

hg strip 123 

Si vous avez une branche déjà existante, vous pouvez éliminer plusieurs révisions à la fois comme celui-ci:

hg phase <start revision>::<end revision> -sf 

pour votre projet de branche secrète ou publique, phase que la dernière révision de ces phases:

hg phase -d tip //assuming you are in the experiment branch 

Ensuite, appuyez sur, et la branche deviendra publique.

Mercurial a été de mieux en mieux à la modification de l'histoire sans changer sa philosophie générale de découragement. Les phases visent à vous protéger contre la modification accidentelle de l'histoire ainsi que de partager ce que vous ne voulez pas.

Comment * I * utilisation des signets

Personnellement, j'utiliser les signets pour le débogage et quand je veux essayer de 2 façons différentes de faire une chose. Pour moi, les signets sont utiles lorsque vous voulez faire des branches anonymes (mettre à jour une révision précédente, commettre et bifurquer l'histoire) mais vous voulez garder les choses intelligibles.

Answer 2

tip n'est pas un concept largement utile dans un référentiel qui a des branches de toute nature. Que vous utilisiez des signets, des branches nommées ou des branches anonymes, tip signifie toujours le commit le plus récent sur n'importe quelle branche, ce qui est rarement quelque chose qui vous tient à cœur. La vraie solution à votre problème est d'arrêter de s'inquiéter de la tip!