Is it possible to checkout all the files in a repository for a specific revision? Say for example that my repository is at revision 88. I don't want to revert or backout any of the changes up to revision 88, but just get a copy of them at revision 50.
To update your working directory to revision <rev>:
hg update -r <rev>
Related
I am using Mercurial ("HG"), I am trying to Clean the repo from uncommitted Changes using :
hg update --clean -R rpeo_path
It will Clean The repo and move to tip ( it will change the changeset )
How can i Clean the repo from uncommitted changes and stay in the current Changeset ?
Thanks in advance
The simplest is probably to use hg revert --all.
With no revision specified, revert the specified files or directories
to the contents they had in the parent of the working directory. This
restores the contents of files to an unmodified state...
The --all option will
revert all changes when no arguments given
I solved :
current_changeset = hg id -i
hg update --clean -R repo_path -r current_changeset
Please keep me updated if you have another opinion
I have a mercurial repo with no uncommitted changes. I was on revision 846, and decided my last 2 commits were junk and wanted to carry on as if from revision 844. So I was going to type:
hg revert -r 844 --all
Unfortunately I mistyped, and wrote:
hg revert -r 44 --all
So my whole repository has changed dramatically, including directory structure. I don't see any .orig files, so I don't think the answer in:
How to undo a revert in mercurial
helps me.
hg log still has all of my commits up to revision 846 - do you think I can revert back to revision 846?
Advice very welcome
hg revert just sets your working copy to the revision that you specify so if you didn't do a commit after the revert then your repository has not changed. To fix it you can just do hg update -C and then delete all the .orig files.
After that you can do the correct revert statement to remove the last two revisions.
If you did do the commit then the command that you wanted to do (hg revert -r 844 --all) would still get you to the point that you want by undoing the revert commit as well as the two commits that you originally intended to undo.
I ran hg update -r REVISION to revert a branch to a previous revision, but when I try to push this to a remote repository it says "no changes found". How can I accomplish this?
To revert the files to a previous revision you can use
hg revert -r REVISION
This will change your working directory files to what they were at that revison. Then you
will need to commit these changes before pushing.
hg update -r REVISION changes the working directory's parent to be that revision as well as changes the contents of the working directory to that revision. This is not what you want here.
hg update only affects the state of your working directory, not the repository itself. If you want to "undo" the effects of one or more previous revisions, you will need to change the repository by committing a new changeset that reflects those changes. You could do it manually but hg's builtin backout command makes this easy to do. See a brief description here. There is a detailed explanation of backout here.
I have a clone of a central repo at rev 2048. I want to remove the last 10 changesets on my local repo as if I was back in time two weeks ago. I suppose I could delete my local repo and do "hg clone -rev 2038" but that would be long (cloning the repo takes several minutes). Is there a way to just "unpull" some changesets?
Notes:
I'm not trying to backout the changesets. I'll eventually pull those changesets again from the central repo.
I'm not trying to update the working directory to an earlier version; I really want to affect the repository.
I don't have any outgoing changesets or pending modifications in my current repo and working directory.
Use the strip command:
hg strip -r 2039
This command is provided by the StripExtension. It is distributed as part of Mercurial 2.8 and later, but you do need to enable it first by adding the following lines to your .hgrc or Mercurial.ini:
[extensions]
strip =
Before Mercurial 2.8, it was part of the MqExtension.
To prevent you from accidentally destroying history, the command will generate a backup bundle in .hg/strip-backup/ which you can hg unbundle again if desired.
Cloning your local repo should be fast. I assume "several minutes" refers to a remote repo?
You can use hg clone <local repo> <new repo> -r <revision> to only clone up to a certain revision.
To remove a changeset that was already committed and pushed use :
hg backout -r (changeset number)
To remove a changeset that was committed but not pushed use :
hg strip -r (changeset number)
For versions previous to Mercurial 2.8, the Strip was part of the MqExtension.
In case you need to Enable the old MQ Extensions,
you can do it by adding this:
[extensions]
hgext.mq =
to your ~/.hgrc (or mercurial.ini) file.
The Strip information used to be here but now it can be found here.
I am looking for best practices to do the following:
When I need to implement a feature or fix a bug, I am creating new Mercurial repository from the main one (a trunk).
Then, within some days, or weeks, I am implementing the task in newly created repository, making commits and periodically merging with trunk. After the code in new repository will pass all code reviews, I should provide a repository with all changes collapsed into single revision.
My common way to do this (rdiff extension should be enabled):
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
patch -p1 < new.diff
hg commit
This works almost well except when there are binary files present in the changes from ~/repos/new. Another way could be:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg pull ~/repos/new
hg update
hg rollback
then resolve possible conflicts and manually commit the changes
Both ways look for me somewhat ugly and non-native, so I am looking how this operation could be simplified. I've played with rebase extension, but seems its hg rebase --collapse command does not work with workflow described above.
Any ideas are welcome.
Sounds like a good case for mercurial queues.
I do something similar with the histedit extension.
My workflow is something like:
clone a central repo
commit incremental changes to local repo
clone my local repo to make collapsed repo
hg histedit and select/discard/fold the revisions as needed
hg push the collapsed repo to central repo
pull central repo to local or refresh local from scratch
I ensure that my local repo never gets pushed to the central repo by adding an invalid default-push path to the .hg/hgrc file in the local repo root directory.
Solved: Just add
[diff]
git = True
to your hgrc file, and then use my first solution with rdiff extension, replacing patch with hg import:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
hg import new.diff
hg commit