I'm having this problem when trying to push to a remote server. It is a Mercurial repository on Phabricator. Here are my output.
hg commit -m "udpate README"
hg push
pushing to ssh://company.server
searching for changes
remote: abort: stream ended unexpectedly (got 0 bytes, expected 4)
I'm using the latest version of Mercurial 3.5.2+20151001 on Mac OS 10.10.
I have this problem from yesterday. During that time, I could successfully committed two times, although I did nothing.
Why the output somewhat looks like this question, the problem here is different, because I have deleted the repository and cloned again many times without any problem. (my first attempt to solve the problem)
The system admin and the server is at another city, so he can't take a look at my machine. Any help would be greatly appreciated.
This looks like there may be a problem with the server and client disagreeing on the new bundle2 format for the wire protocol introduced in 3.5. I'd recommend trying to temporarily downgrade to 3.4.2 (e.g. with pip install mercurial==3.4.2) to see if it fixes this. See this discussion on Phabricator. If it doesn't work, hg push --debug --traceback can provide more information on what exactly went wrong.
Related
I updated my Ubuntu installation which updated my mercurial version, and now hgsubversion doesn't work anymore. I keep getting an error that says "abort: No module named repo!" My copy of hgsubversion seems to be up to date with http://hg.durin42.com/hgsubversion/.
hgsubversion doesn't seem to be actively maintained, but the error wasn't too hard to fix. Taking a look at the relevant source file shows that this error isn't the real error, but is from attempting to recover from the real error. Apparently repository was moved from mercurial into mercurial.interfaces, so changing the line above peerapi=1 to from mercurial.interfaces.repository import peer as peerrepository resolves the issue. I would file a bug report, but I was unable to find a place to report it, so I put it here.
Edit: Right, the file in question that needed editing was hgsubversion/svnrepo.py
My copy of hgsubversion seems to be up to date with http://hg.durin42.com/hgsubversion/
You have to use good and correct location as source of extension:
hg.durin42.com/hgsubversion is not maintained at least 18 months
* real hgsubversion repository now is at https://foss.heptapod.net/mercurial/hg-git
tip of this repo is a lot fresher and have all fixes, needed for HG v5
>hg log -r tip --style compact
1702[tip] d6ac1ae9027a 2020-08-04 00:23 +0200 a
gitnodekw: do not crash on hg incoming when log template includes gitnode()
On the rights of idea: you try to use TortoiseHG on your Ubuntu, which seems to have slightly more newest hgsubversion in library
I'm getting errors when pushing and pulling from a repo on a server. We have a repository (a folder) on a LAN-server which we push our commits to. This worked from the beginning but now it seems to not find the changesets on the server anymore, so tortoisehg ends up by trying to push all the revisions it locally has, to the server.
Also, when I view the repository on the LAN-server in HG workbench, it doesn't show any revision, the only one I can see is a revision -1?
So my question is, what have could gone wrong? And is there a way to fix this? I already replaced the repository on the server with my local one, and that went well for a few days until it happened again.
Revision -1 is what mercurial shows on an empty repository right after a hg init without any commit whatsoever.
If your LAN server exports the repository over a windows network share, indeed it might have been a serious bug fixed in Mercurial 3.3.2 (see https://bz.mercurial-scm.org/show_bug.cgi?id=4546 - maybe you can reproduce that with a new test repo. Upgrade, if that's the case for you)
What Mercurial version are you using?
It's possible that you have been impacted by the bug fixed in Mercurial 3.3.2 (released yesterday).
The solution in that case is to upgrade to Mercurial 3.3.2.
I am on ubuntu 12.04 and using hg 2.5.2
I did a hg init and am trying to clone a repository using hg clone, hg dies with the following error
transaction abort!
rollback completed
abort: integrity check failed on 00changelog.i:16630!
I am pretty sure the repository isn't corrupted because I cloned the same repository on three or four other machines, this is specific to my machine.
Sometimes it fails with different errors (corrupted MAC on input) or at different points integrity check failed on 00changelog.i:11090!
Please help. Thanks
Try to run hg verify on remote repository and on your local copy. What does it say?
Update your Mercurial to the newest version.
Do you clone on hard drive? Then try to clone on another hard drive or on USB drive. And vice versa: if you clone on USB drive then try to clone on hard drive. Bad storage devices are a common reason of repository corruption as people say in comments to this answer.
Looks like there is some optimization that is turned on by default in Ubuntu 12.04 onwards.
This fixed the problem
ethtool -K eth0 rx off tx off
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.
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.