Thu, 15 Oct 2020 21:44:03 -0700 backout: leverage cmdutil.check_incompatible_arguments()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Oct 2020 21:44:03 -0700] rev 45739
backout: leverage cmdutil.check_incompatible_arguments() Differential Revision: https://phab.mercurial-scm.org/D9216
Mon, 12 Oct 2020 12:52:45 -0700 transaction: use ProgrammingError for when an committed transaction is used
Martin von Zweigbergk <martinvonz@google.com> [Mon, 12 Oct 2020 12:52:45 -0700] rev 45738
transaction: use ProgrammingError for when an committed transaction is used It seems to me that ProgrammingError is the right type of error here. Differential Revision: https://phab.mercurial-scm.org/D9215
Mon, 05 Oct 2020 17:18:39 -0400 hook: ignore EPIPE when flushing stdout/stderr
Mitchell Plamann <mplamann@janestreet.com> [Mon, 05 Oct 2020 17:18:39 -0400] rev 45737
hook: ignore EPIPE when flushing stdout/stderr This fixes the bug described in the parent commit. test-transaction-rollback-on-sigpipe.t is updated to show the new behavior. Differential Revision: https://phab.mercurial-scm.org/D9152
Mon, 05 Oct 2020 13:23:16 -0400 test: add test-transaction-rollback-on-sigpipe.t demonstrating py3 regression
Mitchell Plamann <mplamann@janestreet.com> [Mon, 05 Oct 2020 13:23:16 -0400] rev 45736
test: add test-transaction-rollback-on-sigpipe.t demonstrating py3 regression When an hg push is interrupted with C-c, the remote [hg serve] command receives SIGPIPE. If a pretxnchangegroup hook fails, the remote hg then tries to rollback the transaction. It begins by printing "transaction abort!\n". This returns EPIPE, but ui.py ignores that error. In python3 (but not python2), this "transaction abort!\n" message stays in a buffer, so future flushes of stderr will try to print the message again, and so those flushes will also hit EPIPE. This test demonstrates such a case where this EPIPE causes the transaction rollback to fail, leaving behind an abandoned transaction. Differential Revision: https://phab.mercurial-scm.org/D9151
Tue, 13 Oct 2020 05:14:37 +0200 upgrade: allow sidedata upgrade to modify revision flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 05:14:37 +0200] rev 45735
upgrade: allow sidedata upgrade to modify revision flag In the process, we fix the lack of HAS_COPIES_INFO flag on upgrade, and test the results. Differential Revision: https://phab.mercurial-scm.org/D9199
Tue, 13 Oct 2020 03:30:49 +0200 sidedata: return enough data to set the proper flag in the future
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 03:30:49 +0200] rev 45734
sidedata: return enough data to set the proper flag in the future If the revision has information relevant to copy tracing, we need to set a dedicated flag in revlog. Currently the upgrade process is failing to do so. Before we teach the upgrade process about flags, we make the information available where we will needs it. Differential Revision: https://phab.mercurial-scm.org/D9198
Tue, 13 Oct 2020 02:49:03 +0200 test: move upgrade run and check earlier in test-copies-chain-merge
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 02:49:03 +0200] rev 45733
test: move upgrade run and check earlier in test-copies-chain-merge We are about to introduce an explicit case for copy tracing after a upgrade. So I am moving the code around beforehand for clarity. Differential Revision: https://phab.mercurial-scm.org/D9196
Tue, 13 Oct 2020 02:45:24 +0200 copies: split creation of the graph and actual checking again
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 02:45:24 +0200] rev 45732
copies: split creation of the graph and actual checking again The re-install the old split. It will be necessary to test that the upgrade process produced a functionally identical result. It will be useful to detect case where the metadata we look at identical, but some other items we did not checked are missing. (spoiler: we will find some bug) Differential Revision: https://phab.mercurial-scm.org/D9195
Thu, 15 Oct 2020 10:28:27 -0700 copy: clarify in help text that `hg co --forget` takes a *destination* file
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Oct 2020 10:28:27 -0700] rev 45731
copy: clarify in help text that `hg co --forget` takes a *destination* file We had a user who tried to pass a source file. The command then fails with `<file>: not unmarking as copy - file is not marked as copied`, so at least it's not just silent, but let's be a little clearer in the documentation. Differential Revision: https://phab.mercurial-scm.org/D9214
Thu, 15 Oct 2020 15:57:31 +0200 test: check server error output in `test-pull-bundle.t`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Oct 2020 15:57:31 +0200] rev 45730
test: check server error output in `test-pull-bundle.t` This is useful to debug test failure when they happens. Differential Revision: https://phab.mercurial-scm.org/D9213
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip