#Tortoisehg tag vs bookmark code
Mercurial Wiki on Using Mercurial Extensions tells that keyring extension is not distributed together with Mercurial proper, which is confirmed by the fact that no code changes in Mercurial between tags 3.6.1 and 3.6.2 either related to keyring or in any way change the internal API. As expected, there was nothing suspicious. To completely cross off TortoiseHg from a list of suspects, I decided to review changes between tags 3.6.1 and 3.6.2.
#Tortoisehg tag vs bookmark password
Looking for password for user anton.gogolev and url Mercurial Distributed SCM (version 3.6.1) Password will not be saved.ĭowngrading to TortoiseHg 3.6.1 fixed the issue: $ hg version Keyring: username not specified in hgrc (or in url). Keyring: base url:, url user:, url pwd: Http auth: user anton.gogolev, password not set Mercurial Distributed SCM (version 3.6.2) My quick testing has shown that the regression started to manifest itself in TortoiseHg 3.6.2 (the hg.exe is the one that comes with TortoiseHg output truncated for readability): $ hg version One thing to note here is that this is decidedly not a TortoiseHg issue per se, since all TortoiseHg is doing is shelling out to Mercurial and parsing the output (in reality, internal workings are quite more complicated, but the essential idea remains the same). Mekk/mercurial_keyring: Issue #49: mercurial_keyring always asks for user/password.tortoisehg/thg: Issue #4401: mercurial_keyring always asks for user/password.The problem is as follows: when operating on URLs that include a username (like Keyring extension keeps on prompting for username and password. Not so long ago, the immensely useful Mercurial Keyring extension has stopped working for certain TortoiseHg versions in a specific scenario.
Investigation: Mercurial Keyring Always Asking for Username and Password To put things into perspective, here is a standard clone operation with Clone Bundles disabled: If it does, a client doing the cloning first downloads the most appropriate bundle (a very fast operation), applies it locally (a very fast operation as well), and then effectively does an additional hg pull against the original repository to fetch any new commits that were pushed since the time the bundle was generated. First it checks whether the server advertises a list of pre-generated bundle files. Here’s what is going on under the hood when a Mercurial client clones a repository from a Clone Bundles-enabled server. If your HgLab installation serves repositories (say, over 100 Mb) or is under heavy load from frequent clones (say, from your build server), this feature will make scaling problems mostly go away. Head over to the Extensibility documentation article to learn more. This feature significantly reduces load on both TeamCity and HgLab. TeamCity Integration Extension uses VCS Post-Commit Hooks to trigger builds in TeamCity. Performance improvements in Clone Bundles.Improved JIRA, Slack and TeamCity Integration Extensions.Reduced memory usage and Large Object Heap optimizations.
Significant performance improvements for all Mercurial-related operations (think faster hg pull and hg push).What HgLab does with Pull Bundles is essentialy it pre-computes and caches, well, bundles that are most likely to be pulled by clients. Now, with Pull Bundles, hg pulls got just so much faster. With Clone Bundles HgLab received performance boost for initial hg clone operations. Starting with this release HgLab now requires Microsoft. HgLab, a behind-the-firewall self-hosted Mercurial server, source control management system and code collaboration platform, has been updated to version 1.14.
0 kommentar(er)
