Retour à l'ancienne révision dans Bazaar
Je veux revenir dans Mon historique de bazaar (changer l'arbre de travail) pour trouver le commit qui a introduit un certain bug.
Je ne veux pas supprimer de commits, il suffit de changer mon arbre de travail jusqu'à ce que je trouve le bug, puis je veux revenir à la dernière révision pour travailler.
Quelles sont les deux commandes pour cela (revenir à un commit précédent et ensuite vérifier laDernière révision à nouveau)?
Merci d'avance.
5 réponses
Pour rétablir l'arborescence de travail à une révision spécifique N:
bzr revert -rN
Pour rétablir l'arborescence de travail à la dernière révision de la branche:
bzr revert
Il y a deux façons de ramener votre arbre de travail dans le temps à la révision N. La première a été mentionnée par d'autres réponses ici:
bzr revert -rN
Cela modifiera tous les fichiers nécessaires pour que votre arborescence de travail corresponde au contenu de la révision N. Si vous exécutez bzr status, tous ces fichiers seront modifiés. Si vous exécutez bzr commit alors tous ces changements en arrière seraient validés et votre révision HEAD ressemblerait maintenant à la révision N.
, pour revenir À la dernière version de votre branche:
bzr revert
Vous pouvez également exécuter bzr update, mais cela pourrait obtenir des révisions plus récentes si votre branche est une caisse.
L'autre option pour remonter dans le temps est la suivante:
bzr update -rN
La différence entre les deux est que bzr update donne l'impression qu'aucun changement n'a été apporté. C'est juste que votre arbre de travail est obsolète.
, pour revenir À la dernière version de votre branche:
bzr update
Pour changer l'arborescence de travail à l'état qu'il avait dans une révision précédente N
bzr revert -r N
Pour mettre À jour votre copie de travail à l'état qu'il a dans la dernière révision:
bzr up
Autres intervenants qui ont répondu avec bzr revert -rN sont certainement correctes dans le sens que c'est la réponse directe à la question, il a été demandé, toutefois, si vous avez un grand nombre de commits à vérifier afin de tester la présence d'un bug, il est beaucoup plus efficace d'utiliser la bissection. Une fois, on m'a présenté un bug où le dernier commit connu était 300 commits, et bissection a trouvé le commit coupable en seulement 8 passes (je veux dire, je n'ai eu qu'à vérifier 8 commits sur 300 dans pour trouver celui qui a introduit le bug).
Http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
Si vous vous sentez submergé par le nombre de commits possibles que vous devez vérifier, cela devrait réduire considérablement la quantité d'effort impliqué!
Vous pouvez utiliser BZR log --forward pour voir vos versions précédentes avec desc tri
Et vous pouvez utiliser BZR revert-R pour changer votre version à la
Si vous voulez revenir à la dernière version, faites simplement BZR revert