Mercurial – revenir à l’ancienne version et continuer à partir de là

J’utilise Mercurial localement pour un projet (c’est le seul repo qui ne pousse ou ne tire nulle part ailleurs).

À ce jour, il a une histoire linéaire. Cependant, la chose sur laquelle je travaille actuellement, je me suis rendu compte est une approche terrible et je veux revenir à la version avant de la lancer et de la mettre en œuvre d’une manière différente.

Je suis un peu confus avec les commandes branch / revert / update -C dans Mercurial. Fondamentalement, je veux revenir à la version 38 (actuellement sur 45) et avoir mes prochains commits avec 38 en tant que parent et continuer à partir de là. Je me fiche de savoir si les révisions 39 et 45 sont perdues pour toujours ou si elles se retrouvent dans une twig sans issue.

De quelle commande / série de commandes ai-je besoin?

 hg update [-r REV] 

Si plus tard vous vous engagez, vous créerez effectivement une nouvelle twig. Ensuite, vous pouvez continuer à travailler uniquement sur cette twig ou éventuellement fusionner celle qui existe déjà.

Voici la feuille de sortingche sur les commandes:

  • hg update modifie la révision parent de votre copie de travail et modifie également le contenu du fichier pour qu’il corresponde à cette nouvelle révision parent. Cela signifie que les nouveaux commits continueront depuis la révision vers laquelle vous mettez à jour.

  • hg revert change uniquement le contenu du fichier et laisse la révision parent de la copie de travail seule. Vous utilisez généralement hg revert lorsque vous décidez de ne pas conserver les modifications non validées apscopes à un fichier dans votre copie de travail.

  • hg branch commence une nouvelle twig nommée. Pensez à une twig nommée comme une étiquette que vous atsortingbuez aux changesets. Donc, si vous faites hg branch red , alors les modifications suivantes seront marquées comme appartenant à la twig “rouge”. Cela peut être un bon moyen d’organiser les modifications, en particulier lorsque des personnes différentes travaillent sur des twigs différentes et que vous souhaitez voir d’où provient une modification. Mais vous ne voulez pas l’utiliser dans votre situation.

Si vous utilisez la hg update --rev 38 , les modifications 39–45 restront comme une impasse – une tête pendante comme nous l’appelons. Vous recevrez un avertissement lorsque vous poussez, car vous allez créer des “têtes multiples” dans le référentiel vers lequel vous poussez. L’avertissement est là, car il est impoli de laisser de telles têtes, car ils suggèrent que quelqu’un doit faire une fusion. Mais dans votre cas, vous pouvez simplement aller de l’avant et hg push --force car vous voulez vraiment le laisser en suspens.

Si vous n’avez pas encore poussé la révision 39-45 ailleurs, vous pouvez les garder privés. C’est très simple: avec hg clone --rev 38 foo foo-38 vous obtiendrez un nouveau clone local contenant uniquement la révision 38. Vous pouvez continuer à travailler dans foo-38 et pousser les nouveaux (bons) changements que vous créez. Vous aurez toujours les anciennes (mauvaises) révisions dans votre clone foo . (Vous êtes libre de renommer les clones comme vous le souhaitez, par exemple, foo to foo-bad et foo-38 to foo .)

Enfin, vous pouvez également utiliser hg revert --all --rev 38 et ensuite valider. Cela créera une révision 46 qui semble identique à la révision 38. Vous continuerez ensuite à travailler à partir de la révision 46. Cela ne créera pas un fork dans l’historique de la même manière explicite que la hg update , mais vous ne vous plaindrez pas. à propos d’avoir plusieurs têtes. Je voudrais utiliser hg revert si je collaborais avec d’autres qui ont déjà fait leur propre travail basé sur la révision 45. Sinon, la hg update est plus explicite.

Je viens juste de rencontrer un cas de nécessité de revenir à un seul fichier à la révision précédente, juste après que je l’ai fait commettre et pousser. La syntaxe abrégée pour spécifier ces révisions n’est pas couverte par les autres réponses, alors voici la commande pour le faire

 hg revert path/to/file -r-2 

Cela -2 retournera à la version avant la dernière validation, en utilisant -1 reviendrait simplement à annuler les modifications non validées actuelles.

IMHO, hg ssortingp -r 39 convient mieux à cette affaire.

Il nécessite que l’extension mq soit activée et présente les mêmes limitations que la “méthode de repo de clonage” recommandée par Martin Geisler: si le fichier de modifications était en quelque sorte publié, il reviendrait (probablement) à votre repo à un moment donné votre repo local.

Après avoir utilisé la hg update -r REV il n’était pas clair dans la réponse sur la façon de valider ce changement pour pouvoir ensuite pousser.

Si vous essayez juste de vous engager après la mise à jour, Mercurial ne pense pas qu’il y ait des changements.

J’ai d’abord dû modifier un fichier (disons dans un fichier README), Mercurial a donc reconnu que j’avais fait un nouveau changement, puis je pouvais le valider.

Cela a ensuite créé deux têtes comme mentionné.

Pour se débarrasser de l’autre tête avant de pousser, j’ai ensuite suivi l’étape No-Op Merges pour remédier à cette situation.

J’ai ensuite pu pousser.

Les réponses ci-dessus ont été très utiles et j’ai beaucoup appris. Cependant, pour répondre à mes besoins, la réponse succincte est la suivante:

 hg revert --all --rev ${1} hg commit -m "Restoring branch ${1} as default" 

${1} est le numéro de la révision ou le nom de la twig. Ces deux lignes font en réalité partie d’un script bash, mais elles fonctionnent correctement si vous voulez le faire manuellement.

Ceci est utile si vous avez besoin d’append un correctif à une twig de la version, mais que vous devez le construire par défaut (jusqu’à ce que nos outils CI soient adaptés et capables de se développer à partir de twigs et de supprimer également les twigs de publication).

Je voudrais installer Tortoise Hg (une interface graphique gratuite pour Mercurial) et l’utiliser. Vous pouvez ensuite cliquer avec le bouton droit de la souris sur une révision sur laquelle vous souhaitez peut-être revenir – avec tous les messages de validation devant vos yeux – et “Rétablir tous les fichiers”. Il est intuitif et facile de faire défiler les versions d’un ensemble de fichiers, ce qui peut s’avérer très utile si vous souhaitez déterminer à quel moment un problème est apparu.