I'm new to Hg. I have a feature that was working, but now isn't. I want to progressively revert changes until I get to a revision where it works. I'm not quite sure what the best way to do this is.
I tried cloning the repo to an old revision, and saw that it worked there. So... how now do I update to subsequent changes? In the cloned repo, the default and tip revision is the one that I cloned it to.
Do I need to apply patches? Shelve changes? I'm not really sure.
I would iterate through the remaining change-sets using
hg pull -r <revision> [<original repo>]
Some docs here: http://mercurial.selenic.com/wiki/Pull
To find the revision exactly at which the feature was missing you can try hg bisect.
you can find it here
tip the latest revision in the repo, default the name of branch which is by default in the repo when you created it. you can add the remaining changesets(changes) by pulling them.
hg help pull
You should use the bisect command to quickly figure out when your feature stopped working. It works as follows:
You start by resetting the bisect state and by marking your current working directory parent revision as bad:
hg bisect --reset
hg bisect --bad
Now make a guess about when you think the feature was working. If you think it was working on June 1st, then you can do
hg update -d '<Jun 1'
The update command is what you use to update the working directory to match a given changeset. See hg help dates for the list of date formats. You should now test this revision and if the feature works here, then you mark it as good:
hg bisect --good
If the feature is not working in this changeset then mark it as bad and update even further into the past:
hg bisect --bad
hg update -d '<May 1'
Repeat this until you find a good revision. When you have found a good revision, Mercurial can begin helping you: the changesets between the good and the bad changesets must contain the bug. Mercurial will help you by keeping track of the list of candidate changesets and help you narrow the list down to a single changeset. It does this by updating you to a changeset roughly in the middle of the candidates and asking you to test this changeset.
After testing, you mark the changeset as good or bad. If you mark it as good, then you know the bug lies further in the future, and if you mark it as bad, then the bug lies further in the past. In either case, you cut away about half of the candidates in each step! This means that you only need 10 steps to test 1024 candidates -- this is the power of logarithms :-) Mercurial will keep track of the candidates and update you to a new spot after each test.
A full session could look like this (I'm just saying good/bad by random here):
% hg bisect --reset % hg bisect --bad % hg update -r -100 61 files updated, 0 files merged, 9 files removed, 0 files unresolved % hg bisect --good Testing changeset 11414:0fa4474bdc2f (99 changesets remaining, ~6 tests) 46 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --good Testing changeset 11439:778377be3662 (50 changesets remaining, ~5 tests) 17 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --bad Testing changeset 11428:4d03c3680400 (25 changesets remaining, ~4 tests) 6 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --bad Testing changeset 11420:a99ef3711890 (13 changesets remaining, ~3 tests) 3 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --bad Testing changeset 11417:6f1d1ed3e19a (6 changesets remaining, ~2 tests) 4 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --good Testing changeset 11418:67bb9d78f05e (3 changesets remaining, ~1 tests) 1 files updated, 0 files merged, 0 files removed, 0 files unresolved % hg bisect --bad The first bad revision is: changeset: 11418:67bb9d78f05e user: Matt Mackall date: Mon Jun 21 13:25:42 2010 -0500 summary: merge: sort arguments to stabilize the ancestor search