hgsubversion fails with "no module named repo" - mercurial

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

Related

mercurial: No usable temporary file name found

I have a repo on a network drive (served by Windows server), with local repos pushing/pulling to it on the various machines I work on.
I just dealt with this problem, and solved it by cloning the repo from the network drive to a local disk, pushing, then cloning it back again. The machine from which I did this had not problem pushing further changes after this.
Now I just tried pushing from my laptop, and this happens:
% hg --debug push "Z:\[main repo]"
pushing to Z:\[main repo]
query 1; heads
searching for changes
all remote heads known locally
listing keys for "bookmarks"
2 changesets found
list of changesets:
2ed25c8975482734e3b9eed828573fd711d26fd8
19a424c011ffd0c887cf1d54ed0b537a6c1af714
adding changesets
add changeset 2ed25c897548
add changeset 19a424c011ff
adding manifests
adding file changes
adding GEM.py revisions
transaction abort!
rollback completed
abort: No usable temporary file name found
[command returned code 255 Thu Mar 09 18:51:11 2017]
The only info pertaining to this error message I have found so far is this, and I definitely have no files named con.*in my project. There are several named con*.py but they have never been a problem, and both the laptop and my workstation are running Windows 7, and I've been working on this project for a few years now.
I have happily pushed from this laptop for over a year, and it was never a problem. I don't really have any good idea where to even start looking. Could it be connected to the fact that my workstation had the main repo opened at the same time? It was definitely not doing anything to it at the time.
Update:
I ran hg verify, and this is what it returns -- no problem as far as aI can tell
% hg --debug verify
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
73 files, 74 changesets, 226 total revisions
[command completed successfully Fri Mar 10 08:58:02 2017]
I had faced the same error as well.
I just ran tortoise hg as as administrator and that fixed it for me
I don't have an answer yet but I would try the following:
Update to the latest mercurial version (4.1) and try again
Verify the repo integrity with hg verify
Although I understand it always worked as is, try to rename all the con.py files. The thing with CON is that it represents a device, I think it comes from DOS times :-)
If I understand correctly, you push to Z:[main repo] where Z: is a Windows share. Try to push to the same repo in another way, with ssh (requires some setup, yes)
Good luck, very bizarre problem :-/

Negative revision when checking HG repository

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.

Mercurial/TortoiseHG - empty or missing revlog for Thumbs.db

I use Tortoise 2.7.1 on a Windows 8.1 machine
I'm trying to push my project to the common repository (Windows Server 2003 R2) and it's aborting with the following message:
abort: empty or missing revlog for image/Thumbs.db
I must add that I recently disabled the creation of Thumbs.db and started to delete the existing ones.
After I got this error, I tried to add Thumbs.db to .hgignore and commit + push. As before, commit was good, but push still gave me the same message.
Any help would be highly appreciated.
Thanks,
Setnara
I had the same problem and solved it in this way:
remove the file ( image/Thumbs.db, in your case) from the disk
in Hg, "forget" for the file ( image/Thumbs.db )
in Hg, "commit"
added the file ( image/Thumbs.db ) again in the directory
in Hg, added the file
in Hg, "commit"
started to delete the existing ones
It looks like you also deleted (probably recursively) some files in the Mercurial repositories and it is (or they are) now corrupted.. :-(
If you can find the repository on the disk, you can check its state with the following command: "hg check" (I do not know if Tortoise has such a command in the menus) and this will tell you if you have a corruption or not.
If this is the case, I'd suggest to make a backup of your files, remove the corrupted repository, and to clone it again from the central common repository, then checkout the files and compare them with the saved ones (you might have worked on some files and not committed them).
Hope it'll help.
I have just had the same problem.
If you still have the files in the trash, there is a possibility that the files in question still exist. If this is the case, you can just restore the files and push.

mercurial update leads to abort (filename too long)

After creating a symlink to a file I checked the file into my repo and it worked fine up to the point when I shared the repo with my teammate who is using Windows (his code goes into branch 'devui', mine is on the default branch).
If I switch from his latest changes (being on branch 'devui') to my default branch using hg upd default I get this message:
abort: could not symlink to '...<complete contents of symlinked file here>...':
File name too long: <symlink-filename>
This occurs after about half of the checkout so only a part of the files will be updated and the rest of the files (after the abort) is missing.
I also tried a fresh clone and hg upd -C default leading to the same result. In the moment my 'default' branch is in an unusable state and I cannot get back to my branch. I can get back to the revision before the 'devui'-branch was created though.
So my question is: Is it possible to skip the bad symlink, ignoring the abort and continue with the rest of the files? (I could recover that file easily).
I'm using mercurial 2.3 on MacOSX (via brew).
Thanks for your help.
This thread from 2010 (much older version of mercurial) suggests cloning the repo on a windows box, which may be unaffected by the problem, and reverting the symlink there.

"Case folding" error trying to clone a mercurial repo

I try to clone a local mercurial repository on windows.
I get this error:
C:\temp\toolkit1.1>hg clone \src\toolkit
destination directory: toolkit
updating working directory
abort: case-folding collision between sdk/Api.h and sdk/api.h
It looks like I changed capitalization of API.H at some point, but I don't know how to resolve this. Any tips?
I am using the version: 1.2.1
This is a problem that sometimes occurs when you work with a Mercurial repository on a case-insensitive file system (Windows). See the Fixing Case Collisions on the Mercurial wiki.
Probably the easiest is if you have access to a Unix computer check out the project there and remove the offending file, merging changes first (if any), then commit and push.
I fixed this by renaming the file in windows to Api.h.old. Committing that. Then renaming to Api.h with corrected capitalization. Commiting again.
Then clone worked.