debugssl: allow a URL to be specified without a local repository This was the original intent, but I bungled the logic. Otherwise if there is a certificate chain issue, the repository can't be cloned in order for there to be a repo object. I think I missed this case because I was inside of a Mercurial clone as I was originally developing and testing this.

record: fix revert -i for lines without newline (issue5651) This is a regression caused by 66117dae87f9. Code prior to 66117dae87f9 seems to miss the "\ No newline at end of file" line. Differential Revision: https://phab.mercurial-scm.org/D528

templatekw: choose {latesttag} by len(changes), not date (issue5659) As Augie reported in the bug, the current heuristic of choosing the best tag of a merge commit by taking the one with newest tag (in terms of tagging date) currently fails in the Mercurial repo itself. Copying the example from Yuya: $ hg glog -T '{node|short} {latesttag}+{latesttagdistance}\n' \ -r '4.2.3: & (merge() + parents(merge()) + tag())' o 02a745c20121 4.2.3+5 |\ | o 86aca74a063b 4.2.3+4 | |\ | | o e6d8ee3c9ec3 4.3-rc+109 | | | | | ~ o | a3ce07e2dde5 4.3.1+2 : | o | 3fee7f7d2da0 4.3.1+0 |/ o 98e990bb7330 4.2.3+3 |\ | ~ o 506d7e48fbe6 4.2.3+2 : o 943c91326b23 4.2.3+0 | ~ It seems to me like the best choice is the tag with the smallest number of changes since it (across all paths, not the longest single path). So that's what this patch does, even though it's costly. Best-of-5 timings for Yuya's command above shows a slowdown from 1.293s to 1.610s. We can optimize it later. Differential Revision: https://phab.mercurial-scm.org/D447

tests: use graph log in {latesttag} tests The tests are much easier to read if one does not have to re-read the setup part all the time to understand the graph shape. Differential Revision: https://phab.mercurial-scm.org/D446

ui: restore behavior to ignore some I/O errors (issue5658) e9646ff34d55 and 1bfb9a63b98e refactored ui methods to no longer silently swallow some IOError instances. This is arguably the correct thing to do. However, it had the unfortunate side-effect of causing StdioError to bubble up to sensitive code like transaction aborts, leading to an uncaught exceptions and failures to e.g. roll back a transaction. This could occur when a remote HTTP or SSH client connection dropped. The new behavior is resulting in semi-frequent "abandonded transaction" errors on multiple high-volume repositories at Mozilla. This commit effectively reverts e9646ff34d55 and 1bfb9a63b98e to restore the old behavior. I agree with the principle that I/O errors shouldn't be ignored. That makes this change... unfortunate. However, our hands are tied for what to do on stable. I think the proper solution is for the ui's behavior to be configurable (possibly via a context manager). During critical sections like transaction rollback and abort, it should be possible to suppress errors. But this feature would not be appropriate on stable.

tests: test behavior of IOError during transactions (issue5658) ui._write(), ui._write_err(), and ui.flush() all trap IOError and re-raise as error.StdioError. If a caller doesn't catch StdioError when writing to stdio, it could bubble all the way to dispatch. This commit adds tests for I/O failures around various transaction operations. The most notable badness is during abort. Here, an uncaught StdioError will result in incomplete transaction rollback, requiring an `hg rollback` to recover. This can result in a client "corrupting" a remote repo via terminated HTTP and SSH socket.

log: mention ui.logtemplate in the help text

hg: avoid relying on errno numbers / descriptions A few tests hardcode errno numbers and/or descriptions in the output, causing test failures on platforms where these values are different. Differential Revision: https://phab.mercurial-scm.org/D362

hg: tolerate long vs. int in test-context.py The file times here can be longs instead of ints on some platforms, which will cause a test failure due to these printing with an L suffix; instead always format with %d which will produce the same output in either case. Differential Revision: https://phab.mercurial-scm.org/D361

setup: fix installing in a mingw environment The addition, in 9a4adc76c88a, of a hack for the MSVC compiler class was overwriting the original class for the Mingw32CCompiler class, leading to an error when the HackedMingw32CCompiler is instantiated. Differential Revision: https://phab.mercurial-scm.org/D329