Gregory Szorc <gregory.szorc@gmail.com> [Sun, 13 Aug 2017 10:58:48 -0700] rev 33821
repository: formalize peer interface with abstract base class
There are various interfaces for interacting with repositories
and peers. They form a contract for how one should interact with
a repo or peer object.
The contracts today aren't very well-defined or enforced. There
have been several bugs over the years where peers or repo types
have forgotten to implement certain methods. In addition, the
inheritance of some classes is wonky. For example, localrepository
doesn't inherit from an interface and the god-object nature of
that class means the repository interface isn't well-defined. Other
repository types inherit from localrepository then stub out
methods that don't make sense (e.g. statichttprepository
re-defining locking methods to fail fast).
Not having well-defined interfaces makes implementing alternate
storage backends, wire protocol transports, and repository types
difficult because it isn't clear what exactly needs to be
implemented.
This patch starts the process of attempting to establish more
order to the type system around repositories and peers.
Our first patch starts with a problem space that already has a
partial solution: peers. The peer.peerrepository class already
somewhat defines a peer interface. But it is missing a few things
and the total interface isn't well-defined because it is combined
with wireproto.wirepeer.
Our newly-established basepeer class uses the abc module to
declare an abstract base class with the properties and methods that
a generic peer must implement.
We create a new class that inherits from it. This class will hold
our other future abstract base classes / interfaces so we can expose
a unified base class/interface.
We don't yet use the new interface because subsequent additions
will break existing code without some refactoring first.
A new module (repository.py) was created to hold the interfaces.
I could have put things in peer.py. However, I have plans to
eventually add interfaces to define repository and storage types.
These almost certainly require a new module. And I figured having
all the interfaces live in one module makes sense. So I created
repository.py to be that future home.
Differential Revision: https://phab.mercurial-scm.org/D332
Jun Wu <quark@fb.com> [Mon, 14 Aug 2017 22:28:59 -0700] rev 33820
util: make nogc effective for CPython
279cd80059d4 made `util.nogc` a no-op. It was to optimize PyPy. But it slows
down CPython if many objects (like 300k+) are created.
For example, running `hg log -r .` without extensions in `hg-committed` with
14k+ obsmarkers have the following times:
before | after
hg | chg | hg | chg
-----------------------------
1.262 | 0.860 | 1.077 | 0.619 (seconds, best of 20 runs)
Therefore let's re-enable nogc for CPython.
Differential Revision: https://phab.mercurial-scm.org/D402
Augie Fackler <augie@google.com> [Wed, 26 Jul 2017 23:47:54 -0400] rev 33819
scmutil: use util.shellquote instead of %r
Changes some output, but also resolves differences with Python 3.
Differential Revision: https://phab.mercurial-scm.org/D301
Boris Feld <boris.feld@octobus.net> [Mon, 14 Aug 2017 11:20:06 +0200] rev 33818
context: fix troubled deprecation
troubled has been renamed into isunstable but troubled was calling unstable
instead. Fix the mistake.
Differential Revision: https://phab.mercurial-scm.org/D384
Matt Harbison <matt_harbison@yahoo.com> [Mon, 14 Aug 2017 22:26:48 -0400] rev 33817
test-pushvars: invoke shell script hook via `sh` for Windows
Invoking *.sh on Windows leads to the "what program should open this?" prompt,
which stalls the test and led to the recent series of exceptions on the Windows
test machine as the runner times out.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 14 Aug 2017 22:20:53 -0400] rev 33816
test-sparse: drop unnecessary globs
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jul 2017 22:04:27 -0700] rev 33815
exchange: simplify unbundle locking using context managers
Differential Revision: https://phab.mercurial-scm.org/D393
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jul 2017 22:42:10 -0700] rev 33814
util: add base class for transactional context managers
We have at least three types with a close() and a release() method
where the close() method is supposed to be called on success and the
release() method is supposed to be called last, whether successful or
not. Two of them (transaction and dirstateguard) already have
identical implementations of __enter__ and __exit__. Let's extract a
base class for this, so we reuse the code and so the third type
(transactionmanager) can also be used as a context manager.
Differential Revision: https://phab.mercurial-scm.org/D392