I want to go back in my bazaar history (change working tree) to find the commit that introduced a certain bug.
I do not want to delete any commits, just change my working tree until I found the bug, and then I want to go back to the latest revision to work on.
What are the two commands for that (going back to an earlier commit and afterwards checking out the latest revision again)?
Thanks in advance.
To revert the working tree back to a specific revision N:
bzr revert -rN
To revert the working tree to the latest revision in the branch:
bzr revert
There are two ways to take your working tree back in time to revision N. The first has been mentioned by other answers here:
bzr revert -rN
That will modify all the files necessary to make your working tree match the contents of revision N. If you run bzr status it will show all those files as changed. If you run bzr commit then all those backward changes would get committed and your HEAD revision would now look like revision N.
To come back to the latest version in your branch:
bzr revert
You could also run bzr update, but that might get some newer revisions if your branch is a checkout.
The other option for going back in time is this:
bzr update -rN
The difference between the two is that bzr update makes it look as though no changes have been made. It's just that your working tree is out of date.
To come back to the latest version in your branch:
bzr update
Other commenters who answered with bzr revert -rN are certainly correct in the sense that that is the direct answer to the question as it was asked, however if you have a large number of commits to check through in order to test for the presence of a bug, it is vastly more efficient to use bisection. One time I was presented with a bug where the last known-good commit was 300 commits ago, and bisection found the guilty commit in only 8 passes (I mean, I only had to check 8 commits out of 300 in order to find the one that introduced the bug).
http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
If you're feeling overwhelmed by the number of possible commits you need to check, this should reduce the amount of effort involved significantly!
To change the working tree to the state that it had in a previous revision N
bzr revert -r N
To update your working copy to the state it has in the latest revision:
bzr up
Bazaar Quick Reference Card
you can use bzr log --forward to see your previous versions with DESC sorting
and you can use bzr revert -r for change your version to the
if you want to revert to the last version just do bzr revert
Related
We've just spent two weeks working down the wrong path on a problem (with all the commits to our SVN repository that go with that). We've now come up with the right solution (which needs our code base to go back to what it was two weeks ago). We should have branched two weeks ago, but that is irrelevant now.
Clearly, I can make a second checkout of the project and then copy that over the current version of the repository and check that in.
Is there a cleaner way to do this without a second checkout?
There are many ways to do what you want. The simplest would be to check out a new copy of the codebase to a dev machine, specifying the revision for the commit made just before you went down the wrong development path. Then, simply check that code back in as the latest revision. Not only do you effectively "revert" the codebase to that revision, if you find out that some element of your wrong solution was useful after all, you still have easy access to those elements.
Also, as was said, you can branch the codebase at any time, at any revision. Simply cut a branch of the revision before you began your work, and continue along your new dev path. Keep in mind that merging this branch back into the trunk could be problematic; you'd want the end result of development in the branch to replace the codebase of the trunk wholesale. That's possible but it can get messy.
There are a few ways of handling this:
Revert your changes:
$ svn merge -r$rev2:$rev1 .
This is assuming that $rev2 > $rev1. This will back out the changes between these two revisions. If you're backing out a single revision, you can use this:
$ svn merge -c -$rev .
That is, the revision should be a negative number. This will back out just that one revision.
Recreate the Branch
If this work was not done on trunk, but on a branch, and you pretty much want to toss out that branch, you can simply recreate the branch, and even delete the old bad one. Branches (and tags) can be created from any point in time:
$ svn cp -r$rev $REPO/branches/$bad_branch/$proj $REPO/branches/$new_branch
$ svn delete $REPO/branches/$bad_branch
The solution provided by Mike works for me.
In a separate branch
$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
(this undoes the change between 302 and 303).
Then you can commit the changes in your branch, test and then merge back to the trunk as normal.
We have two heads. One is our main development head and the other is one that I forgot about until today. We found a bug and fixed it in our main development branch, and I just realized it should be fixed in the older branch as well.
I think it would have been better to make the change on the older branch and merge that with the up-to-date branch, but we didn't do it that way. Can mercurial handle this? We haven't tried to do anything like this and I can't really wrap my head around how it would be done.
Yes, you have two good options:
Graft: new in Mercurial 2.0
This version introduced the graft command which can backport changes in an intelligent way. The "intelligence" is that it will use merges internally and this means that you get
Support for renames: Imagine that you fixed the bug in file foo.c on the development branch. In the older maintenance branch foo.c was called bar.c. Using hg graft, the change to foo.c can be correctly merged into the old bar.c.
Three-way merges: Grafting involves twisting the graph around and merging in that temporary graph. The advantage of three-way merges is that you can use your normal graphical merge tool to resolve conflicts.
To copy the tip of default onto old-branch you simply run
$ hg update old-branch
$ hg graft default
Transplant: older versions
Before we had the graft command, the transplant extension was the way to go. This simple extension will export a changeset as a patch and try to apply the patch onto some other revision.
Because we're dealing with "dumb" patches things like renames will not be taken into account and you will not get support for your merge tool since there is no three-way merge. Despite of this, I've found that transplant works really well in practice.
Using transplant is simple:
$ hg update old-branch
$ hg transplant default
This is very close to running
$ hg update old-branch
$ hg export default | hg import -
except that transplant also adds a piece of meta data that records the original changeset in the transplanted changeset. This can be used to skip future transplants.
I'm new to mercurial and I read that it's not possible to merge only a separate changeset from another branch.
Then I don't know what's the best approach to solve that:
I start with an stable revision R1
I continue developing on R1: CS1,CS2,CS3
At some point I need to solve bug from my stable revision R1. And I want to apply only one changeset from developing line (fe CS2)
What's the best aproach? As merging didn't work what I've done is make a patch of CS2 and then apply the patch in the new stable branch to fix the bug. That's the Mercurial way?
Cheers,
UPDATE: No need for any extension anymore as of Hg 2.0
As 'CAD bloke' pointed out, this is exactly what the graft command is for which was introduced in Hg 2.0.
SourceTree
The easiest way to do this is with a GUI like SourceTree, just double-click on the TARGET branch to switch, then press the right mouse button on any other revision and select the 'Graft' command (strangely it can also be a revision of the current branch).
If there are no conflicts SourceTree will immediately create a new revision for the current branch.
TortoiseHg
Exactly the same, select TARGET Branch, then rmb over the revision you want to graft: How to graft with TortoiseHg
Command Line
To do this with the command line just switch to the TARGET branch and then execute
hg graft -r {revision_number}
with {revision_number} obviously being the number of the revision you want to incorporate into you current branch. This will create a new changeset in you current branch with all the files from the revision whose number you used in the command.
To find out more about the graft command read this thread here on stackoverflow
The transplant extension automates what you've done to a single command.
But I think the preferred way (which depending on the scenario isn't always possible) is to make the fix on top of R1 in the first place, and then merge that to your development tip.
That is:
Start with stable revision R1.
You do some work, cs1...csN.
An important fix is needed for stable on top of R1, so you hg update R1.
Do the fix, this yields R2.
Go back to where you left off, hg update csN.
Merge stable so you have the fix, hg merge R2, hg commit...
Continue working on csN+1.
I've been working on a fork of critical component of our source tree, and I'm interested to see how many changes have been made. I originally bzr branch'd the project, but because of paralell development I have been doing a bzr merge to stay up-to-date.
How can I see only the changes I've been commiting in this branch?
THANK YOU!
According to bzr documentation submit: revision identifier can be used to see only your changes, so running in your branch
bzr diff -r submit:
should show you your changes without merged changes.
You can also inspect the diff of your changes how they will look after merge to the trunk, run
bzr merge --preview YOUR_BRANCH
in the main branch (trunk).
from command line:
bzr log --forward > somefile.txt
View the file, any commit that is not labeled [merge] happened on that branch. I hope this answers your question. Perhaps I'm reading it wrong. BTW the --forward bit will cause the history to be placed in somefile.txt in forward chrono order rather than the default revers chrono.
When using Mercurial, how do you undo all changes in the working directory since the last commit? It seems like this would be a simple thing, but it's escaping me.
For example, let's say I have 4 commits. Then, I make some changes to my code. Then I decide that my changes are bad and I just want to go back to the state of the code at my last commit. So, I think I should do:
hg update 4
with 4 being the revision # of my latest commit. But, Mercurial doesn't change any of the files in my working directory. Why not?
hg revert will do the trick.
It will revert you to the last commit.
--all will revert all files.
See the link for the Man Page description of it.
hg update is usually used to refresh your working directory after you pull from a different repo or swap branches. hg up myawesomebranch. It also can be used to revert to a specific version. hg up -r 12.
An alternative solution to hg revert is hg update -C. You can discard your local changes and update to some revision using this single command.
I usually prefer typing hg up -C because it's shorter than hg revert --all --no-backup :)
hg revert is your friend:
hg revert --all
hg update merges your changes to your current working copy with the target revision. Merging the latest revision with your changed files (=current working copy) results in the same changes that you already have, i.e., it does nothing :-)
If you want to read up on Mercurial, I'd recommend the very awesome tutorial Hg Init.
hg revert --all
and then
hg pull -u
works for me