Fri, 15 Sep 2017 18:57:50 +0200 hgwebdir: read 'web.template' untrusted stable
Boris Feld <boris.feld@octobus.net> [Fri, 15 Sep 2017 18:57:50 +0200] rev 33678
hgwebdir: read 'web.template' untrusted The 'hgweb_mod.py' version of this read it untrusted. For consistency we align the two versions of this code.
Mon, 11 Sep 2017 15:59:18 -0700 ssh: fix flakey ssh errors on BSD systems stable
Durham Goode <durham@fb.com> [Mon, 11 Sep 2017 15:59:18 -0700] rev 33677
ssh: fix flakey ssh errors on BSD systems This is a trivial backport of c037fd655b47 performed by augie@google.com, but the change is still really Durham's not mine, so I [augie] am leaving him as the author.
Thu, 14 Sep 2017 11:16:57 -0700 repair: preserve phase also when not using generaldelta (issue5678) stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Sep 2017 11:16:57 -0700] rev 33676
repair: preserve phase also when not using generaldelta (issue5678) It seems like we used to pick the oldest possible version of the changegroup to use for bundles created by the repair module (used e.g. by "hg strip" and for temporary bundles by "hg rebase"). I tried to preserve that behavior when I created the changegroup.safeversion() method in 3b2ac2115464 (changegroup: introduce safeversion(), 2016-01-19). However, we have recently chagned our minds and decided that these commands are only used locally and downgrades are unlikely. That decicion allowed us to start adding obsmarker and phase information to these bundles. However, as the bug report shows, it means we get different behavior e.g. when generaldelta is not enabled (because when it was enabled, it forced us to use bundle2). The commit that actually caused the reported bug was 8e3021fd1a44 (strip: include phases in bundle (BC), 2017-06-15). So, since we now depend on having more information in the bundles, let's make sure we instead pick the newest possible changegroup version. Differential Revision: https://phab.mercurial-scm.org/D715
Thu, 14 Sep 2017 11:16:47 -0700 tests: add test for issue5678 stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Sep 2017 11:16:47 -0700] rev 33675
tests: add test for issue5678 In addition to a test case for the direct problem described in the bug report, this also adds a test case showing how obsmarkers can also get lost when not using generaldelta. Differential Revision: https://phab.mercurial-scm.org/D714
Mon, 11 Sep 2017 00:42:24 +0200 mq: create non-lossy patches, also with custom global diff configuration stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 11 Sep 2017 00:42:24 +0200] rev 33674
mq: create non-lossy patches, also with custom global diff configuration Users with custom [diff] configuration most certainly didn't intend it to make mq lose changes. It could: * git is handled perfectly fine. * nobinary could make mq leave some files out from the patches. * noprefix could make mq itself (and probably also other tools) fail to apply patches without the usual a/b prefix. * ignorews, ignorewsamount, or ignoreblanklines could create patches with missing whitespace that could fail to apply correctly. Thus, when refreshing patches, use patch.difffeatureopts, optionally with git as before, but without the config options for whitespace and format changing that most likely will cause loss or problems. (patch.diffopts is just patch.difffeatureopts with all options enabled and can be replaced with that.)
Mon, 11 Sep 2017 00:42:22 +0200 mq: test coverage of how [diff] configuration influence can break mq patches stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 11 Sep 2017 00:42:22 +0200] rev 33673
mq: test coverage of how [diff] configuration influence can break mq patches
Tue, 29 Aug 2017 16:38:10 -0400 debugssl: allow a URL to be specified without a local repository stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 29 Aug 2017 16:38:10 -0400] rev 33672
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.
Sun, 27 Aug 2017 13:39:17 -0700 record: fix revert -i for lines without newline (issue5651) stable
Jun Wu <quark@fb.com> [Sun, 27 Aug 2017 13:39:17 -0700] rev 33671
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
Tue, 15 Aug 2017 23:23:55 -0700 templatekw: choose {latesttag} by len(changes), not date (issue5659) stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Aug 2017 23:23:55 -0700] rev 33670
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
Fri, 18 Aug 2017 12:50:26 -0700 tests: use graph log in {latesttag} tests stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Aug 2017 12:50:26 -0700] rev 33669
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
Tue, 15 Aug 2017 13:04:31 -0700 ui: restore behavior to ignore some I/O errors (issue5658) stable
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 15 Aug 2017 13:04:31 -0700] rev 33668
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.
Mon, 14 Aug 2017 13:12:40 -0700 tests: test behavior of IOError during transactions (issue5658) stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 14 Aug 2017 13:12:40 -0700] rev 33667
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.
Wed, 16 Aug 2017 10:24:49 -0500 log: mention ui.logtemplate in the help text stable
Nathan Goldbaum <ngoldbau@illinois.edu> [Wed, 16 Aug 2017 10:24:49 -0500] rev 33666
log: mention ui.logtemplate in the help text
Sat, 12 Aug 2017 14:29:22 +0200 hg: avoid relying on errno numbers / descriptions stable
Tristan Seligmann <mithrandi@mithrandi.net> [Sat, 12 Aug 2017 14:29:22 +0200] rev 33665
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
Sat, 12 Aug 2017 14:24:25 +0200 hg: tolerate long vs. int in test-context.py stable
Tristan Seligmann <mithrandi@mithrandi.net> [Sat, 12 Aug 2017 14:24:25 +0200] rev 33664
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
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip