Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Oct 2020 21:48:43 -0700] rev 45740
import: leverage cmdutil.check_incompatible_arguments()
Differential Revision: https://phab.mercurial-scm.org/D9217
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
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
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
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
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
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
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