A bug has been introduced in the code base I'm working on and I'm attempting to see which changset introduced it. Here's what I've done so far:
Cloned the release branch
$ hg clone https://hg.mozilla.org/releases/mozilla-release/
Marked the tip as bad
$ hg bisect --bad
Marked the last working changeset I'm aware of working as good
$ hg bisect --good 5500ee2a6206
abort: starting revisions are not directly related
What does this error mean? I'm not quite sure I understand what it's saying. If I run the command once more I get a different message:
$ hg bisect --good 5500ee2a6206
abort: inconsistent state, 275567:5500ee2a6206 is good and bad
I've only marked it as good, how can it be bad as well?
Related
I'm using mercurial Hg in command line. After created a patch, I needed to revert to another changeset due to some errors happened later. Now it's needed to refresh the patch file. When executing Hg qref it says, abort: working directory revision is not qtip. Also, hg parent is a tip.
I'll add an answer to help other people that may encounter the same error message in the future. I'm not sure our issues was identical but definitely related.
I got "abort: working directory revision is not qtip" while trying to apply a patch onto my working directory.
It turned out that I had older patches in the patch queue which caused the problem and after I deleted these and tried again it worked!
Here's what I did:
Opened a console window and navigated to the working directory where I entered the command:
hg qseries
this listed the patch queue. Then to delete the old patches I entered:
hg qdelete [patch name (which was just listed)]
The response in my case was "abort: cannot delete applied patch ..." and to resolve this I entered:
hg qpop
This unapplied the patch and then I could use the "hg qdelete" command again which now work. Repeated this until all old patches were gone and tried to apply the new patch again.
Found the solution in the "Mercurial: The Definitive Guide", written by Bryan O'Sullivan, under section 12.7.1. http://tortoisehg.bitbucket.io/hgbook/1.4/managing-change-with-mercurial-queues.html#id2858507
Hope someone finds this useful!
It happened due to popping the current head out of the queue. In order to refresh, the patch should have been taken into the head of the queue by qpush.
Is there a problem with Mercurial's guide for fixing case-folding collisions or is there a problem with the way I am implementing the solution.
The solution as provided on the Mercurial wiki is as follows:
hg clone -U repo repair
cd repair
hg debugsetparents <bad revision>
hg debugrebuildstate
At this point, Mercurial will think you have the bad revision checked
out and all the files are missing (status '!'). To fix the repo, we
simply have to do:
hg rm -A <file causing the collision>
Now hg st should show the troublesome file in state 'R' and all other
files in state '!'. Now we can check in our fix:
hg ci -m"fix case collision"
To get all our files back, we just check out again:
hg co tip
The problem files are: SomeFile.bash and Somefile.bash. I originally had Somefile.bash and I would like it to now be SomeFile.bash. Also to note, version 157 is happy, no collision, but version 158 is where I have introduced the collision. The head of the repository is currently at revision 160.
I have implemented this solution as follows:
hg clone -U my-repo-url repair
cd repair
hg debugsetparent 160
hg debugrebuildstate
hg status (reveals that everything is 'missing' (!))
hg rm -A Somefile.bash (responds that SomeFile.bash has been removed, notice case change)
hg ci -m "Fixed the collision... I hope."
hg co tip
hg update -C tip
According to the guide, this should have removed the case-folding collision and brought the rest of the missing files back, yet another hg status reveals that everything is still missing (!).
Edit: By appending that last command (the update) to the existing commands, I was able to recover the missing files which solved the remainder of the problem.
Note: I had to use the most recent 'problem' version for <bad revision> to fix this problem (that was 160 in my case).
Try
hg update -C tip
That should bring the files back. If not, try reverting everything:
hg revert -r tip -a
Occasionally when performing a rebase using the MercurialEclipse plugin my repository gets thrown into an odd state. It will become stuck in a "rebasing" state, yet when I try to abort the rebase (e.g. "hg rebase -a") I get this error message:
abort: unknown revision 'xxxx'!
Where xxxx is a revision hash. Usually at this point I've abandoned all hope of performing the rebase -- I just want to get back to a happier time when my repository was not screwed up. So far my solution has been to nuke my project directory and clone it again. Is there a less drastic solution?
Just remove the .hg/rebasestate and your repo will work.
The patch described in this thread calls the internal function clearstate which just unlinks this file.
In situations similar to this, I usually do:
$ hg check
$ hg verify
$ hg up -C default
Instead of default, use whatever branch you're working on. This takes time, but so does re-cloning the repo.
It usually helps.
I've got a repository. In the middle of its life-cycle I deleted a lot of unnecessary files from it (I decided to keep them unversioned).
hg remove
hg commit
The repo grows bigger and bigger.
And I decided to get rid of old revisions the from initial one to the revision where lot of files were removed (let's name it X).
Other words I want combine these revisions (from the initial to the X) into one initial revision.
But same time to keep the history of the following revisions (X+1, etc..) as they are.
I googled for the solution, but failed.
And found nothing clever than do this:
hg init newrepo
cd oldrepo
hg archive -r X newrepo
hg export -r X+1: -o "~/patches/%R-%h.diff"
cd newrepo
hg commit -A -m 'initial release (after archiving)'
hg import ~/patches/*.diff
And damn it, after few successfully applied patches
I receive:
Hunk #1 FAILED at xxx
Hunk #2 FAILED at xxx
2 out of 2 hunks FAILED -- saving rejects to file xxx.rej
abort: patch failed to apply
What I do wrong?
I've got 1 repo without branches (to be more exact to the revision X all branches were merged).
The second solution was
* hg convert to svn
* hg convert to mercurial from revisiob X+1
Failed with python backtrace (probably it was caused by our repo has about 3K files).
To filter out files from repository, you want to use hg convert (Mercurial to Mercurial) with --filemap argument (see documentation for more details). Keep in mind the affected changeset IDs (and those of all their descendants) will change.
Take a look at the Collapse extension which seems to do what you want.
You can fold changesets with MQ, or use histedit extension
Mercurial newbie here, I have a simple question.
I deleted one of my files from Mercurial and I want to get it back. I used to do svn up in Subversion, but in Mercurial it doesn't work, I tried hg up, and it does nothing.
I tried hg up to a specific file, and surprisingly (to me..) it told me:
abort: unknown revision '74656d706c617465732f6c6f67696e2e68746d6c'!
I tried to specify a revision and it told me:
abort: please specify just one revision
Isn't there a simple way of doing what I want?
Use hg revert.
hg revert -r REV path/to/file
where REV is the revision of the repository that contains the file you want to recover. See hg help revert for details.