When cloning a repository which contains a sub-repository (from a remote HTTP repository that requires authentication) and using the Mercurial keyring extension hg prompts for a password when it should use the stored password. I reproduced this with these steps (using Rhodecode as the remote repository): 1. Create a remote repository (eg http://myserver/Test) 2. Create another remote repository (eg http://myserver/Subtest) 3. Create an [auth] entry to provide the username for myserver 4. Enable the Keyring extension 5. Clone Test locally (c:\Test) 6. Clone Subtest locally (c:\Test\Subtest) 7. Create .hgsub with Subtest = ../Subtest and add 8. Create a file in Subtest and add 9. Commit Subtest and then Test 10. Push Test to remote repository 11. At this point there should have only been a single password prompt. 12. Clone Test from the remote server to another directory. 13. It will prompt for the password again. This is with version 2.0.2. Looking at the debug output and inspecting the traffic on the wire it looks like Mercurial is sending the listkeys command to the remote server twice in a row. The keyring interprets the duplicate requests as indicating there was an authorization failure and doesn't use the stored password for the second request. I think the problem is in hgsubrepo._get (subrepo.py) where it clones the subrepo and then calls bookmarks.updatefromremote. I think it should only call bookmarks.updatefromremote when using pull, not clone.
keyring is a third-party extension, their BTS is that-a-way -> https://bitbucket.org/Mekk/mercurial_keyring/issues
I realize that keyring is a third party extension but the problem in keyring is just a symptom of the fact that hg is sending the listkeys command to the remote server twice in a row. In Mercurial revision 13754 a change was made to specifically avoid calling listkeys twice in a row but revision 14305 broke that when it added code to use clone to populate an empty subrepo. Since fixing this in hg would both fix the issue with keyring and improve performance (by only doing the listkeys command once) I though you would want to make the fix, especially because there was a previous change to avoid the duplicate call. If you still don't think this should be fixed I'll enter an issue for keyring but I don't know how they will differentiate between this duplicate call and one that truly represents a bad password.
Hey eblood66, These revision numbers you mentioned only apply to your local repository. Please mention the hashes instead.
Oops, forgot that. :) 13754 = 31eac42d9123 14305 = ccb7240acf32
I think your analysis is correct. I've queued a fix, thanks.
Fixed by http://selenic.com/repo/hg/rev/4bc715f2a356 Matt Mackall <mpm@selenic.com> subrepo: avoid syncing bookmarks twice on clone (issue3191) (please test the fix)
I tested 4bc715f2a356 with a repository containing several subrepositories hosted with RhodeCode. I used mercurial_keyring to store the password. The stored password was only used for the parent repository. I still had to type in my password for each subrepository. I took a look at mercurial_keyring. It looks like mercurial_keyring used the command arguments to determine if a stored password can be reused. Since changeset http://selenic.com/repo/hg/rev/ce99d887585f (issue2126) the command arguments are sent as HTTP headers instead of GET. This might cause the problems with the subrepositories.
My testing revealed the same thing as keimlink. This fix did remove the duplicate listkeys messages that had the same argument (namespace=bookmarks) but mercurial_keyring acted the same as before because there were two listkey messages in a row but with different arguments (one with namespace=bookmarks and one with namespace=phases). However, that seems like a problem that mercurial_keyring needs to solve rather than something that requires a change in Mercurial itself. I will submit an issue for mercurial_keyring for that issue. The mercurial issue seems to be fixed.
There are several issues in the mercurial_keyring issue tracker complaining about this problem. But Marcin (the current maintainer) has no time to fix this. I took a look at the code and it's a huge monkeypatch on top of mercurial. And AFAIU it can't access the HTTP headers. I'm working on getting mercurial_keyring inside the core to avoid the monkey patch and to solve the authentication problem with subrepositories. But the patch is not ready yet.
Ok, moving this to the done state. keimlink: post early and often, please.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:26 EDT --- This bug was previously known as _bug_ 3191 at http://mercurial.selenic.com/bts/issue3191