I recently upgraded to TortoiseHg 3.6.2 x64 and since then the mercurial_keyring setting does not work. I had previously followed the instructions here (the ones that show how to enable mercurial_keyring extension). Here's what I have:
Mercurial.ini
[extensions]
mercurial_keyring =
Local Repo .hg\hgrc
[paths]
http://username#repo.url/repo.hg
Now, ever time I try to pull/push etc from TortoiseHg, I am asked for my username and password. When I disable mercurial_keyring, then I am just asked for my password.
If I downgrade to TortoiseHg 3.5.2 x64 then it works again.
Any ideas please? Is there a minimum compatible server-side Mercurial version for this to work with TortoiseHg 3.6.2? I think we are running 2.7.1 on the server under Linux.
Thanks.
This appears to be a change in behaviour caused by TortoiseHg 3.6.2. It looks to me like a bug, although as of yet is unconfirmed if it was an intentional change or not.
The relevant mercurial_keyring issue is here. The only reason I wonder if it's intentional or not is that the current docs state:
Simpler form with url-embedded name can also be used:
[paths] bitbucket = https://John#my.server.com/hgrepo/someproject/
but is not recommended.
The workaround appears to be to specify the username outside of the URL.
[paths]
myremote = https://my.server.com/hgrepo/someproject
[auth]
myremote.prefix = https://my.server.com/hgrepo
myremote.username = John
Related
It seems that Bitbucket has now blocked TLS 1.0 and 1.1.
I am working in Eclipse on Mac OSx 10.12.6 using the MercurialEclipse (hg) 2.2 plugin.
I was receiving SSL handshake errors whenever I tried to pull from the remote Bitbucket repository.
I tried updating the plugin and doing a fresh install, but it still gave the same error.
Then I tried downloading and installing the latest Mercurial package (4.8) from the mercurial web site.
After doing this the error changed to this:
warning: connecting to bitbucket.org using legacy security technology
(TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for
more info abort: error: [SSL: WRONG_VERSION_NUMBER] wrong version
number (_ssl.c:590)
I tried downloading the latest Python, both 3.7.1 and 2.7.15 as I read on Mercurial's site linked in the warning that that it had something to do with Python's OpenSSL implementation, but I still get the same error.
Any suggestions on how I can get Mercurial to work with Bitbucket via TLS 1.2?
I tried the
[ui]
tls = False
This worked for me, though I do not get why. bitbucket only uses tls 1.2, and this seems like it would turn it off. Does anyone know why this worked? It is just bugging me.
I was on Mac OS X 10.12 "Sierra". I updated to 10.13 "High Sierra" and it fixed the issue.
Notably... when I run openssl version now, I get: LibreSSL 2.2.7. Where as before on 10.12 I got: OpenSSL 0.9.8zh 14 Jan 2016.
As you i had the same issue , i had done the above mentioned solution in my VirtualMachine that solved the problem though, whereas in my realtime server this did not solve. The only option you got left is changes your hgrc file within the repository ie "reponame/.hg/hgrc" and update the default path to "ssh://hg#bitbucket.org/'reponame'" instead of "https:#bitbucket.org/'reponame'" its not a good solution but will work until Bitbucket support team comes up with some solution.
Doing this has solved my issue.
Just a Suggestion can you create a "hgrc" file and add
[ui]
tls = False
and give it a try.
I upgraded to Tortoise 3.6.3 yesterday and now I am prompted every time I pull or push a repo. The keyring is set properly, and my user name is in the url.
Any ideas on what may be wrong? Did 3.6.3 break keyring?
Issue 4401 "mercurial_keyring always asks for user/password" from time of 3.6.2 closed as pure extension-specific and contains solution: don't use username in URL anymore
Here is what to put into .hg/hgrc:
[auth]
default.username=myname
default.prefix=http://myrepo
A good way to debug issues like this is to run merciural from the command line with the debug flag, as in:
hg pull --debug
This will clearly indicate if there are problems getting the repo, user name, and password.
UPDATE: A new version of TortoiseHG has been released (3.8.3 at the time of writing) and fixes this issue: upgrading to latest version should be enough.
I had this exact same problem and found the following investigation article to be quite helpful to better understand what't going on (I'm not the author, BTW).
To cut it short, it seems a bug of the mercurial_keyring extension v1.0.1, introduced in TortoiseHG 3.6.2, which also appears to be fixed in v1.1.1.
If you're into Python compiling, it should be possible to upgrade it manually into TortoiseHG by getting it from its official bitbucket repo, compile it and manually place it into TortoiseHG's /lib/library.zip file (backup it beforehand might be wise): if you're not, you have 2 options:
1) clone the bitbucket repo to your HDD and then configure your Mercurial installation to use the new version of that extension module by writing the following in your C:\Users\USERNAME\mercurial.ini file (which was what I did):
[extensions]
mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
(Notice: you might also have to put the path in your PATH or PYTHONPATH env variable, depending if you already have Python and/or Mercurial installed on your machine).
2) wait for the next TortoiseHG release that will contain the updated version.
I have recently updated to eclipse juno. I have also updated mercurial to its latest version, but it is still giving me problems. The mercurial plugin tells :"Unsupported hg version:1.9.3. Expected is at least2.0.0." but its already updated(see pic).
If I try to commit, it automatically opens preferences window, which gives message :"Mercurial is not configured correctly.Run 'hg debuginstall' to analyse.".
When I do that, it says:"no username supplied". Then I run "hg -y debuginstall", which says, no problems were detected.
Everything that I mentioned is depicted in the picture.
Uncheck the option labelled Use default (built-in) Mercurial executable; then in the text box labelled Mercurial executable below, you can enter the full path to the hg.exe under your TortoiseHg 2.5 installation.
I got the same error when I installed Mercurial Eclipse Plugin. I find the configuration file "Mercurial.ini" in the mercurial installation folder. In my case, the path of that folder is "E:\eclipse\plugins\com.intland.hgbinary.win32_2.3.2\os\win32". Edit the configuration file with notepad and add the line "username = your-user-name" where your-user-name is free to choose. I hope it would help.
I'm really new with SCM systems, so I'm starting to study Mercurial, but I'm facing a problem that I have no idea how to fix. I hope someone can point me the right direction :-) :
So, I have installed the BitNami Redmine Stack (http://bitnami.org/stack/redmine) on a Vmware computer with windows 2003 (64 Bits) as the OS. On the same VM I have installed Mercurial-2.3 (Mercurial 2.3 Inno Setup installer - x64 Windows - does not require admin rights) , and restarted. after that , created a directory (e:\helloworld) and I have initialized the directory with some basic the HG commands (HG Init, HG Add, HG Commit).
Using the host computer to confirm the correct communication with the VMWare guest computer, I have created a small project in Redmine, added a repository with Mercurial as the SCM and included the initialized directory (e:\helloworld on the server). The repository is displayed correctly in Redmine, and, working directly in the virtual computer if I do some changes and perform some commits, the changes are displayed in the Redmine repository. From my current limited knowledge, all seems to be ok when I work directly in the VM, but when I try to clone the directory using HG clone from the host computer, the server responds:
C:\helloworld>hg clone http://redminevm/redmine/projects/helloworld
abort: HTTP Error 406: Not Acceptable
I also have tried with the IP address instead of the hostname, adding the username and the password to the URL, or initializing the local folder previous to try the hg clone. all my attemps return the same result. I'm assuming something is incorrect in the server, but I have no idea what it can be.
What should review on the server (or Client), in order to allow me to clone the Mercurial repository thru http?
Thank you very much in advance!
Alex.
Ok, after investigating, and with a big help from the Redmine forum, I can answer my own question. I hope my experience can help someone. My question was because of lack of knowledge about Redmine and what it can and cannot do.
so;even if we can have repositories in a RedMine project, RedMine is not a repository server. Means I can link a repository to a project, but, if I want work on it thru http (or serve multiples repositories) , aditionally I need install a server like rhodecode, or use hg serve. :-)
Saying this, I was doing this incorrectly. After running hg serve , I was able to serve multiples repositories.
Same error if you want to clone a git repo with "hg clone". Yeah, I know, I'm an idiot, but it happens, probably this will help someone.
I'm running tortoisehg 2.1.3 (and now 2.1.4) on a win7 x86 system upgraded from 2.1.2. When I click on the context menus (e.g. workbench) nothing happens.
I enabled shell debugging: [HKCU]\Software\TortoiseHg\ value DebugShellExt="1"
Which yielded: [THGx86] RunDialog: THG root is empty in DbgView.
I've manually checked that \Software\TortoiseHg\ default is "C:\Program Files\TortoiseHg" for both [HKCU] and [HKLM]. Though I'm having some problems where installing TortoiseHg seems to make these registry keys empty and unreadable and I have to manually change ownership on them to even delete them.
Anyone else having problems with these context menus in this version of TortoiseHg on windows? Anyone know if something has changed in the installer? Anyone know of something that could cause these registry keys to become inaccessible even to the application that created them?
It looks like the issues are resolved in more recent versions of TortoiseHG (2.2.1 and later). So, I'm marking this question answered.