I'm trying to build a script that checks the status of a web server and revert to the previous stable revision if an error occurs. Is there a way to return to the previous revision before the tip without knowing the revision number?. Something like this:
$ hg update --rev tip-1
hg update -r -2 is the revision before the tip. hg update -r -1 is the last revision (the tip).
This isn't necessarily the direct ancestor of the tip, though. Consider:
0--1---3
\
---2
tip is rev 3. hg update -r -2 will select rev 2.
hg update tip~1 selects the direct ancestor of the tip, or rev 1.
See hg help revisions and hg help revsets.
Related
I need to revert back to a particular revision.
For accomplishing the same, i am using the following command:
hg revert -r REV
(Reference - here)
But the problem is that even though i know the nodeid of that particular revision (the one to which i want to revert), but i do not know the revision number.
is there any way in which i could get the revision number(REV) from that nodeid?
Please help me out here - I am new to using Mercurial
Thanks in advance.
You need hg identify to answer your question and use -n to report back the local revision id:
hg identify -n -r <hash>
To make it really simple, most hg commands take both the local id or the global hash as valid identifiers so you could just use
hg revert -r <hash> --all
My followup question is this: Why are you reverting a changeset? To change your working directory to a particular point in the history you use
hg update -r <hash>
and then continue your development from there by creating a new (unnamed) branch.
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
I run hg pull which added new changes to my repository. Before updating my working directory with the new changes i would like to see these new files/changes. I believe in SVN i used svn st -u but how is it done in Mercurial?
Before you even pull you can use:
hg incoming --stat
to see a summary of changes or
hg incoming --patch
to see the actual deltas.
After pulling (but before updating!) you can do:
hg status --rev tip
to see a list of the changed files, or
hg diff --rev tip
to see a summary of the changes, or
hg diff -r tip
to see the combined diff.
(After pulling the changes via hg pull) you can run hg status --rev tip to show an output similar to svn st -u.
There is also hg incoming (alias hg in; additionally hg outgoing/hg out) which can be used before pulling which will show you the revisions which will be pulled. At times this can be useful.
Basically, what I want to try is pulling hg revisions from a branch of an experimental repo into a clone of mainline. But I want to discard the branch name so I can push directly into the server-side mainline repo. It's probably best to give a simple example:
hg init hg_mainline
pushd hg_mainline
touch foo
hg add foo
hg commit -m 'foo'
popd
hg clone hg_mainline hg_experimental
pushd hg_experimental
hg branch bar_branch
touch bar
hg add bar
hg commit -m 'bar'
popd
pushd hg_mainline
hg pull ../hg_experimental
hg log
As you can see, the mainline now includes a rev with "branch: bar_branch." I don't want this revision to have a branch (i.e. it should be default).
It is okay if this requires rewriting history with rebase, transplant, or another tool. I have tried both of these, but couldn't get it working. The most recent revision hash may end up different between the two repos.
So I want the topmost revision of hg_mainline to look like:
changeset: 1:xxxxxxxxxxxx
tag: tip
user: ...
date: ...
summary: ...
with no named branch.
Again, it's okay if the hash isn't preserved from hg_experimental.
I am currently using hg 1.6.2+55-18e1e7520b67 from an Ubuntu PPA.
EDIT:
I also used 1.3.1. I tested the below on both, and the results here are the same.
I got it working with transplant, but only with the grep -v kludge.
hg transplant -s ../hg_experimental 1 --filter "grep -v '^branch:'"
With:
hg transplant -s ../hg_experimental 1
hg export didn't work either, with or without an appropriate grep.
The changeset patch looks like:
# HG changeset patch
# User Matthew Flaschen <EMAIL>
# Date 1282942390 14400
# Branch bar_branch
# Node ID b8e36efea72642f0a0194301489d5c48f619a921
# Parent 85d9b9773d4ec09676dfcc4af89c142c46279444
bar
I exported from experimental with:
hg export 1 -o '/tmp/%b_%H_%R'
and tried to import to mainline with:
hg import /tmp/hg_experimental_b8e36efea72642f0a0194301489d5c48f619a921_1
It fails with:
abort: no diffs found
EDIT 2:
As noted, the export method failed only because the files were empty. It works correctly with --git or with non-empty files.
The simplest solution is use hg export from the experimental repo, and hg import into the main repo. By default, hg import won't apply any branch information in the patch. The downside is that they'll show up as different changesets in the two repos -- hg incoming in the experimental repo will show the changes you just exported/imported -- so after you do this, you may be better off deleting and recreating the experimental repo if you plan on doing any more experimentation.
EDIT: From the hg_mainline repository:
hg export -r 1 -R ../hg_experimental | hg import -
EDIT2: From hg help diffs:
Mercurial's default format for showing changes between two versions of a file
is compatible with the unified format of GNU diff, which can be used by GNU
patch and many other standard tools.
While this standard format is often enough, it does not encode the following information: (snip)
creation or deletion of empty files
The test files are empty in your test script, so you need to either enter something into them, or use the --git option to hg export.
The transplant extension already scraps the branch name:
cd hg_mainline
hg transplant -s ../hg_experimental 1
should do it for you. If you're finding that's not the case you can always use the --filter modify the changesets (perhaps just using grep -v) on the way in.
I will note that if you can come up with a work flow that avoids transplant and retains hashes you're better off. Avoiding named branches entirely makes this easier -- anonymous branches perhaps with bookmarks work as well or better.
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