smtp: add the class to verify the certificate of the SMTP server for STARTTLS Original "smtplib.SMTP" has no route to pass "ca_certs" and "cert_reqs" arguments to underlying SSL socket creation. This causes that "getpeercert()" on SSL socket returns empty dict, so the peer certificate for STARTTLS can't be verified. This patch introduces the "STARTTLS" class derived from "smtplib.SMTP" to pass "ca_certs" and "cert_reqs" arguments to underlying SSL socket creation. Almost all code of "starttls()" in this class is imported from "smtplib.SMTP" of Python 2.7.3, but it differs from original code in points below: - "self.ehlo_or_helo_if_needed()" invocation is omitted, because: - "ehlo_or_helo_if_needed()" is available with Python 2.6 or later, and - "ehlo()" is explicitly invoked in "mercurial.mail._smtp()" - "if not _have_ssl:" check is omitted, because: - "_have_ssl" is available with Python 2.6 or later, and - same checking is done in "mercurial.sslutil.ssl_wrap_socket()" - "ssl.wrap_socket()" is replaced by "sslutil.ssl_wrap_socket()" for compatibility between Python versions - use "sock.recv()" also as "sock.read()", if "sock" doesn't have "read()" method with Python 2.5.x or earlier, "sslutil.ssl_wrap_socket()" returns "httplib.FakeSocket"-ed object, and it doesn't have "read()" method, which is invoked via "smtplib.SSLFakeFile".

template: allow unquoted int function arguments

Merge with main

graft: use missing ancestors algorithm to find earlier grafts When the revisions to graft are numerically close to the destination, this avoids two walks up the DAG, which for a repository with over 470,000 changesets translates to around 2.2 seconds.

graft: find ancestors of destination lazily When the revisions to graft are numerically close to the destination, this avoids one walk up the DAG, which for a repository with over 470,000 changesets translates to around 1.1 seconds.

merge with crew

sslutil: try harder to avoid getpeercert problems We wrap both calls to getpeercert in a try/except to make sure we catch its bogus AttributeError.

copies._forwardcopies: use set operations to find missing files This is a performance win for a number of reasons: - We don't iterate over contexts, which avoids a completely unnecessary sorted call + the O(number of files) abstraction cost of doing that. - We don't check membership in a context, which avoids another O(number of files) abstraction cost. - We iterate over the manifests in C instead of Python. For a large repo with 170,000 files, this improves perfpathcopies from 0.34 seconds to 0.07. Anything that uses pathcopies, such as rebase or diff --git between two revisions, benefits.

perf: add a command to test copies.pathcopies perf An upcoming patch will improve the performance of this function, and this command will be used to demonstrate that improvement.

merge with stable

Added signature for changeset 8a7bd2dccd44

Added tag 2.5.4 for changeset 8a7bd2dccd44

applyupdates: assign variable before we try to use it (issue3855) The variable 'fd' was getting used with a value left over from a prior iteration, causing a KeyError: '.hgsubstate'.

merge with mpm

perf: add a command to test addremove performance Upcoming patches will improve addremove performance. This command will be used to demonstrate that improvement.

merge with crew

dirstate: only call lstat once per flags invocation This makes a big difference to performance in some cases. hg --time locate 'set:symlink()' mozilla-central (70,000 files): before: 2.92 sec after: 2.47 another repo (170,000 files): before: 7.87 sec after: 6.86

util: add functions to check symlink/exec bits These are not yet used.

Merge with stable.

setup.py: properly discard trust warning. This modification was missing from the fa91ddfc3f36 changeset.

scmutil.addremove: use iteritems on walk results Now that we no longer sort all the walk results, using iteritems becomes possible. This is a relatively minor speedup: on a large repository with 170,000 files, perfaddremove goes from 2.13 seconds to 2.10.

scmutil.addremove: stop sorting all walk results The only place where the order matters is in printing out added or removed files. We already sort that set. On a large repository with 170,000 files, this speeds up perfaddremove from 2.34 seconds to 2.13.

scmutil.addremove: pull ui.status printing out of the loop This will let us stop sorting all the results in an upcoming patch. This also permits future refactorings where the same code consumes dirstate.walk results but doesn't print anything out. An argument could be made that printing out results as we go along is more responsive UI-wise. However, at this point iterating through walk results is actually faster than sorting them, so once we stop sorting all the results the argument ceases to be valid.

scmutil.addremove: remove redundant directory and symlink checks dirstate.walk only does lstats and never returns stat objects for directories. On a large repository with 170,000 files, this speeds perfaddremove up from 2.40 seconds to 2.34.