Due to unknown reasons an HG command failed with the message:
abort: abandoned transaction found - run hg recover!
But when I tried to use recover to get rid of the abandoned transaction, I got a different error:
$ hg recover
rolling back interrupted transaction
attempted to truncate path/to/file to 12345 bytes, but it was already 456 bytes
and it aborted. The actual file was named like:
_some_filename.cs.i
which is an internal HG data file. So it seems like the HG data records for some_filename.cs are badly clobbered. And indeed running hg verify shows errors like this:
# hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
warning: revlog 'data/project/folder/some_filename.cs.i' not in fncache!
13691: empty or missing project/folder/some_filename.cs
project/folder/some_filename.cs#13691: manifest refers to unknown revision b269f6036278
project/folder/some_filename.cs#13741: manifest refers to unknown revision 651b96abf6da
...
(goes on for a long time)
which corroborates that the file is damaged but doesn't do anything useful to fix it.
hg recover --help doesn't show anything else that I can do...
And aside from the apparent damage to this one file, no ordinary HG commands work at this point. All of them report the repository is damaged. How can I recover from this?
I concluded that this was just a situation that HG was not designed to deal with. For whatever reason HG's internal data file (the .i file) was destroyed.
It was helpful to review the HG source code which produced the key error:
if fp.tell() < o:
raise error.Abort(
_(
b"attempted to truncate %s to %d bytes, but it was "
b"already %d bytes\n"
)
% (f, o, fp.tell())
)
(https://fossies.org/linux/mercurial/mercurial/transaction.py)
I'm not especially familiar with HG internals but this seemed to make it clear enough that HG was not able to handle the situation (understandably - arbitrary destruction of one of its data files leaves few options!).
The best workaround I could come up with was to manually copy the damaged .i file from another copy of the repository (on another PC). I didn't actually have local changes to that source file, so this seemed reasonable.
I copied the file (replacing the damaged original having made a backup first).
Then ran hg recover. This was now able to resolve the original "abandoned transaction" issue. Other HG commands work as well.
Worth noting that running hg verify still reports some errors (though many fewer). Perhaps the history of this single file is still not right; ultimately I think I will need to re-clone this repository but at least I can complete my immediate tasks without losing any work.
How do you make the mercurial "diff" command produce output that is compatible with the unix or unxutil patch command?
I need to create a patch file that I can send to a coworker who doesn't have Mercurial installed.
I've tried using hg diff -r 3:5 > patch1.diff and I get an error from the patch command when applying it. (hold on, I will post the error message as soon as I have a chance....)
OK, here is a test case that I've uploaded to bitbucket:
hg clone https://bitbucket.org/jason_s/test-patch-apply P2base
hg update -r 2 -R P2base
hg diff -r 2:4 -R P2base > p2base.patch
rm -r P2base/.hg
cd P2base
patch < ../p2base.patch
I get this on my Windows PC:
C:\tmp\hg\P2base>patch < ../p2base.patch
patching file bar.txt
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Never mind, this is a documented problem (with a REALLY POOR ERROR MESSAGE) that can be overcome. From http://gnuwin32.sourceforge.net/packages/patch.htm :
On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be
used as line endings. A file with LF may give the error: "Assertion
failed, hunk, file patch.c, line 343," unless the option '--binary' is
given.
I used --binary and it worked fine.
I clone a new repository by TortoiseHg version 2.1.3. Then do some change. When I do commit, I get this message as below.
My desktop drive mapping is connected to Linux server by Samba.
I am so appreciate if someone can help.
% hg commit --repository V:\htdocs\critical\mysite2 --verbose --user MyUser --message=testing Mercuial V:\htdocs\critical\mysite2/application/controllers/package.php
smartdox/application/controllers/package.php
transaction abort!
rollback completed
abort: The process cannot access the file because it is being used by another process
[command returned code 255 Fri Jan 13 14:30:17 2012]
mysite2%
For me changing the setting:
Global Settings -> TortoiseHg -> Monitor Repo Changes
to
localonly
helped.
The long discussion in the official bug tracker: https://bitbucket.org/tortoisehg/thg/issue/889/
I've seen this same problem, but I've noticed that "occasionally" I am able to commit changes. I think the 'another process' is something on the server.
When I fail to commit, hg gives an error saying (among other things) "transaction abort! rollback failed - please run hg recover".
If I run hg recover, sometimes that fails, too (in use by another process). If I wait a minute or two, then retry to recover, it often succeeds.
Once the recovery succeeds, if I wait another minute or two, then the commit often succeeds when I retry it.
My theory is that the server is indexing or virus-scanning the contents of .hg/
I don't know a guaranteed work-around, but on my small repository I can often get my changesets in if I give it a try or two. Your luck is likely to increase as the activity on your repository files decreases.
I don't really know about committing, but I know that Mercurial/TortoiseHG has issues when you push to a Linux drive which is mapped under Windows.
See these answers I wrote about it:
Mercurial remotes on the file system instead of http server
Can you 'push' to network share using Mercurial on 64bit Windows 7?
Maybe the same problems occur when the repository you're trying to commit to directly resides on a mapped Linux drive.
I'd suggest that you put the repository on a real Windows drive and try if you can commit there.
If yes, the problems you described are probably because of the Linux drive.
I'm receiving a "missing revlog" error when using Mercurial (via TortoiseHg). Does anybody know how to fix this repo?
% hg --repository C:\Source\Project verify --verbose
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
data/MyProject.Class.Library.Tests/Part/FileName.cs.orig.i#1: missing revlog!
1: empty or missing MyProject.Class.Library.Tests/Part/FileName.cs.orig
MyProject.Class.Library.Tests/Part/FileName.cs.orig#1: fb25dd9d5f41 in manifests not found
4384 files, 1354 changesets, 12803 total revisions
3 integrity errors encountered!
(first damaged changeset appears to be 1)
[command returned code 1 Wed May 11 13:31:14 2011]
You can try to use convert extension with convert.hg.ignoreerrors set to True, as described on the wiki. Keep in mind that this will modify the hashes, and damaged files will probably be lost completely.
The Mercurial wiki has a page on Repository Corruption. If the solution suggested by #Cat Plus Plus does not work for you, then you may attempt to reconstruct the revlog.
There is a section with step-by-step instructions for reconstructing missing revlogs. However, you must have a copy o the problem file as it existed in the "bad" revision.
In your case, you would need an exact copy of data/MyProject.Class.Library.Tests/Part/FileName.cs.orig as it existed in revision 1 of the repo.
Got a bluescreen in windows while cloning a mercurial repository.
After reboot, I now get this message for almost all hg commands:
c:\src\>hg commit
waiting for lock on repository c:\src\McVrsServer held by '\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
interrupted!
Google is no help.
Any tips?
When "waiting for lock on repository", delete the repository file: .hg/wlock (or it may be in .hg/store/lock)
When deleting the lock file, you must make sure nothing else is accessing the repository. (If the lock is a string of zeros or blank, this is almost certainly true).
When waiting for lock on working directory, delete .hg/wlock.
I had this problem with no detectable lock files. I found the solution here: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError
Here is a transcript from Tortoise Hg Workbench console
% hg debuglocks
lock: user None, process 7168, host HPv32 (114213199s)
wlock: free
[command returned code 1 Sat Jan 07 18:00:18 2017]
% hg debuglocks --force-lock
[command completed successfully Sat Jan 07 18:03:15 2017]
cmdserver: Process crashed
PaniniDev% hg debuglocks
% hg debuglocks
lock: free
wlock: free
[command completed successfully Sat Jan 07 18:03:30 2017]
After this the aborted pull ran sucessfully.
The lock had been set more than 2 years ago, by a process on a machine that is no longer on the LAN. Shame on the hg developers for a) not documenting locks adequately; b) not timestamping them for automatic removal when they get stale.
Coworker had this exact problem today, after a BSoD while trying to push. He had to:
delete the file .hg/store/lock (as per the accepted answer)
delete the file .hg/store/phaseroots (as per this TortoiseHG bug report)
Then his repo worked again.
EDIT: As per #Marmoute's comment - when dealing with lock-related issues, using hg debuglock is a safer alternative to blindly deleting the .hg/store/lock file.
I am very familiar with Mercurial's locking code (as of 1.9.1). The above advice is good, but I'd add that:
I've seen this in the wild, but rarely, and only on Windows machines.
Deleting lock files is the easiest fix, BUT you have to make sure nothing else is accessing the repository. (If the lock is a string of zeros, this is almost certainly true).
(For the curious: I haven't yet been able to catch the cause of this problem, but suspect it's either an older version of Mercurial accessing the repository or a problem in Python's socket.gethostname() call on certain versions of Windows.)
I had the same problem. Got the following message when I tried to commit:
waiting for lock on working directory of <MyProject> held by '...'
hg debuglock showed this:
lock: free
wlock: (66722s)
So I did the following command, and that fixed the problem for me:
hg debuglocks -W
Using Win7 and TortoiseHg 4.8.7.
I had the same problem on Win 7.
The solution was to remove following files:
.hg/store/phaseroots
.hg/wlock
As for .hg/store/lock - there was no such file.
I do not expect this to be a winning answer, but it is a fairly unusual situation.
Mentioning in case someone other than me runs into it.
Today I got the "waiting for lock on repository" on an hg push command.
When I killed the hung hg command I could see no .hg/store/lock
When I looked for .hg/store/lock while the command was hung, it existed. But the lockfile was deleted when the hg command was killed.
When I went to the target of the push, and executed hg pull, no problem.
Eventually I realized that the process ID on the hg push was lock waiting message was changing each time. It turns out that the "hg push" was hanging waiting for a lock held by itself (or possibly a subprocess, I did not investigate further).
It turns out that the two workspaces, let's call them A and B, had .hg trees shared by symlink:
A/.hg --symlinked-to--> B/.hg
This is NOT a good thing to do with Mercurial. Mercurial does not understand the concept of two workspaces sharing the same repository. I do understand, however, how somebody coming to Mercurial from another VCS might want this (Perforce does, although not a DVCS; the Bazaar DVCS reportedly can do so). I am surprised that a symlinked REP-ROOT/.hg works at all, although it seems to except for this push.
If the locked repo was the original, I can't imagine it was modifying it to clone it, so it was only preventing you from changing it in the middle and messing up the clone. It should be fine after removing the lock.
The new cloned copy (if it was a local clone) could be in any sort of malformed state, though, so you should throw it out and start it over. (If it was a remote clone, I would hope it failed and already threw out the incomplete copy.)
I encountered this problem on Mac OS X 10.7.5 and Mercurial 2.6.2 when trying to push. After upgrading to Mercurial 3.2.1, I got "no changes found" instead of "waiting for lock on repository". I found out that somehow the default path had gotten set to point to the same repository, so it's not too surprising that Mercurial would get confused.
If it only happens on mapped drives it might be bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share. Using UNC path instead of drive letter seems to sidestep the issue.