When trying a
hg commit
or
hg status
I'm getting the error
abort: invalid subrepository revision specifier in .hgsubstate line 3
This is probably why:
f322ee070c467d1e517564d679f150693739d186 buildtools
2e68a7e2306704c8dc98802c73897c6c43bf96bc dzlivetemplates
libs/dxgettext
libs/dzlib
libs/jcl
libs/jvcl
libs/tregexpr
The first two lines look OK, but starting from the 3rd line there is no GUID for the subrepository revision.
I have no idea how this happened (but I probably caused it myself).
How do I recover from this? Can I just delete the .hgsubstate file and have hg recrate it from the current state of the subrepositories? If yes, how?
OK, deleting the file (actually I renamed it to be able to restore it) seems to solve the issue.
hg update
hg commit
restored it.
Now I'm back with the original problem: Getting rid of the unintentionally created second head. But that's a different story.
Related
I have a situation where I renamed a few files I was tracking in a mercurial repo without using hg rename command (just doing it via the file system).
This occured several revisions ago
Now I want to return to a revision prior to the file renames, fix a bug, and then rebuild that old revision
problem i have is that i am getting error messages along the lines of:
remote changed file.txt which local deleted
use (c)hanged version or leave (d)eleted?
Is there a way I can fix the mistake I made when renaming the files all those revisions ago?
Depends on whether you committed the deletion of the files, but I assume you didn't and it doesn't seem so.
Then you can simply revert them in order to restore them to your working dir: hg revert file.txt. After that you can update to the previous revision without this question popping up. Alternatively just update to the previous revision you want to fix and accept the (c)changed version from remote.
If you want the rename to be permanent and also tracked by the repository, then commit that rename. Use hg addremove, possibly check with --dry-run first what it does so that no unwanted changes are added and commit the renaming of the files. Then go and update to the old revision and do whatever changes you want to commit there.
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.
I accidentally stripped the wrong changesets; however, I saved backups, but when I try to unbundle them using hg unbundle .hg/strip-backup/faa0a1895b97-backup.hg, I get the following error:
adding changesets
transaction abort!
rollback completed
abort: 00changelog.i#561fe01204b5: unknown parent!
What can I do to correct this?
Here's the entire output from hg verify:
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
If unbundle is telling you that it can't apply the bundle then the parent of that "first" changeset it that bundle, the bundles base, doesn't exist in your repo. Since repos never lose changesets using normal mercurial commands (strip isn't normal) then it seem you used strip or some other history-altering-not-normal-usage command to alter or remove that changeset.
Try going through all the .hg/strip-backup/ files and applying them one by one. Maybe one of them does apply and contains the parent the the strip backup you're trying to apply requires.
Tl;Dr: no normal mercurial command ever deletes anything, and the non-normal ones that do create backups. Unless you deleted the file out of band the data is there somewhere.
Im trying to run the following command but its producing errors.
hg backout -r 2 -u Fraz --merge
The log of my repository is as follows:
Im a little lost as to why i can back out the 2nd changeset. When i run the above command, i get the commit gui appearing, i add a comment, save, close. Then i get a merge error, see below. Could someone please explain why this is happening?
EDIT seems to have something to do with the .bak file i had. Ive just rerun it via notepad and no errors occured. Also note, my comment on the first proposed answer is wrong. It adds a new changeset to repository which specifically undo's the specified changeset, hence why a merge is then necessary as u have two heads.
Backout is not undo - it basically allows to re-apply a changeset in reverse, undoing the changes of it.
Now if changes were done to the parts changed in the changeset to be backed out, you'll have to deal with the merge as you see it because the backout cannot be automatically applied (what should happen with the portions that are to be backed out but changed since the commit of the changeset to be backed out?).
After resolving the conflicts you should be able to successfully complete the operation.
I have done a 'hg merge' however when I attempt to do a 'hg commit -m "my msg.." I get the following error message :
abort: cannot commit merge with missing files
Can anyone explain how to fix this to allow the commit go through?
Try hg status and look for files in state ! (missing).
The cause is that one of the files which is part of the merge has been deleted. Undelete the file and try again.
Heres my approach
hg status will tell you what files are missing. Then you can either restore the file from somewhere
OR type in hg remove <path/name of missing file>
THEN commit. Your repo will be sane again, darwin willing.
If you are using TortoiseHG, click in View/Commit. It will show you files in state ! (missing).
Right click on the file and choose Revert (undelete the file) and commit.