dirstate: simplify dirstate's __iter__ Probably also a performance win, but not measurable in perfdirstate. Differential Revision: https://phab.mercurial-scm.org/D269

repo: skip invalidation of changelog if it has 'delayed' changes (API) The changelog object can store recently added revisions in memory until the transaction is committed. We don't want to lose those changes even if repo.invalidate(clearfilecache=True), so let's skip the changelog when it has such 'delayed' changes. Differential Revision: https://phab.mercurial-scm.org/D152

httppeer: make several instance attributes internal (API) Peer instances are supposed to conform to a well-defined API so consumers can be agnostic about the underlying peer type. To reinforce this, this commit renames a handful of instance attributes on httpeer so they no longer have a "public" name. Differential Revision: https://phab.mercurial-scm.org/D268

httppeer: remove unused handler attribute The consumer of this attribute was removed by b6bd4ee6ed85 in 2008. Differential Revision: https://phab.mercurial-scm.org/D267

localrepo: remove unused requirements attributes on localpeer (API) The previous changeset removed the last consumer of requirements. I'm not sure when supportedformats became unused. But I couldn't find any obvious instances where it is being used. It likely stems from peers being derived from repository instances several years ago and is a holdover from that day. Differential Revision: https://phab.mercurial-scm.org/D266

exchange: access requirements on repo instead of peer As part of formalizing the peer interface, I audited for attribute accesses for non-internal names to find API violations. This uncovered the code changed in this commit. localpeer.requirements is just an alias to the repo's requirements attribute. So, change the code to get the data from the source instead of relying on a one-off attribute in the localpeer type. Differential Revision: https://phab.mercurial-scm.org/D265

exchange: drop support for lock-based unbundling (BC) Locking over the wire protocol and the "addchangegroup" wire protocol command has been deprecated since e8c4f3d3df8c, which was first part of Mercurial 0.9.1. Support for handling these commands from sshserver was dropped in 9f6e0e7ef828 in 2015, effectively locking out pre 0.9.1 clients from new servers. However, client-side code for calling lock and addchangegroup is still present in exchange.py and the various peer classes to facilitate pushing to pre 0.9.1 servers. The lock-based pushing mechanism is extremely brittle. 0.9.1 was released in July 2006 and I highly doubt anyone is still running such an ancient version of Mercurial on a server. I'm about to refactor the peer API and I don't think it is worth keeping support for this ancient protocol feature. So, this commit removes client support for the lock-based pushing mechanism. This means modern clients will no longer be able to push to pre 0.9.1 servers. Differential Revision: https://phab.mercurial-scm.org/D264

http: add a test of actually pushing with httppostargs This was previously untested. Sigh. Differential Revision: https://phab.mercurial-scm.org/D230

filemerge: move decorator definition for internal merge tools to registrar This patch also adds extra loading entry for internal merge tools to extensions.py, for similarity to other decorators defined in registrar.py. This patch uses "internalmerge" for decorator class name, instead of original "internaltool", because the latter is too generic. BTW, after this patch, 4-spaces indentation is added to the 1st line of internal merge tool description docstring, and this may make already translated entries in *.po fuzzy. Even though this indentation is required for "definition list" in reST syntax, absence of it has been overlooked, because help.makeitemsdoc() forcibly inserts it at generation of online help. But this forcible insertion causes formatting issue (I'll send another patch series for this). Therefore, this additional indentation should be reasonable.

releasenotes: add similarity check function to compare incoming notes It is possible that the incoming note fragments have some similar content as the existing release notes. In case of a bug fix, we match for issueNNNN in the existing notes. For other general cases, it makes use of fuzzywuzzy library to get a similarity score. If the score is above a certain threshold, we ignore the fragment, otherwise add it. But the score might be misleading for small commit messages. So, it uses similarity function only if the length of string (in words) is above a certain value. The patch adds tests related to its usage. But it needs improvement in the sense of combining incoming notes. We can use interactive mode for adding notes. Maybe we can do this if similarity is under a certain range.