Gregory Szorc <gregory.szorc@gmail.com> [Thu, 10 Aug 2017 20:58:28 -0700] rev 33827
wireproto: use new peer interface
The wirepeer class provides concrete implementations of peer interface
methods for calling wire protocol commands. It makes sense for this
class to inherit from the peer abstract base class. So we change
that.
Since httppeer and sshpeer have already been converted to the new
interface, peerrepository is no longer adding any value. So it has
been removed. httppeer and sshpeer have been updated to reflect the
loss of peerrepository and the inheritance of the abstract base
class in wirepeer.
The code changes in wirepeer are reordering of methods to group
by interface.
Some Python code in tests was updated to reflect changed APIs.
.. api::
peer.peerrepository has been removed. Use repository.peer abstract
base class to represent a peer repository.
Differential Revision: https://phab.mercurial-scm.org/D338
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 18:00:19 -0700] rev 33826
httppeer: use peer interface
This is similar to what we did to sshpeer. Quirks and all.
Differential Revision: https://phab.mercurial-scm.org/D337
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 17:59:48 -0700] rev 33825
sshpeer: use peer interface
We need the same @property conversion of ui like we did for localpeer.
We renamed _capabilities() to capabilities() to satisfy the new
naming requirement.
However, since we're inheriting from wireproto.wirepeer which inherits
from peer.peerrepository and provides its own code accessing
_capabilities(), we need to keep the old alias around. This wonkiness
will disappear once wirepeer is cleaned up in subsequent commits.
We also implement methods for basepeer that are identical to the
defaults in peer.peerrepository in preparation for the removal of
peerrepository.
Differential Revision: https://phab.mercurial-scm.org/D336
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 09 Aug 2017 23:52:25 -0700] rev 33824
localrepo: use peer interfaces
We now have a formal abstract base class for peers. Let's
transition the peer classes in localrepo to it.
As part of the transition, we reorder methods so they are grouped
by interface and match the order they are defined in the interface.
We also had to change self.ui from an instance attribute to a
property to satisfy the @abstractproperty requirement.
As part of this change, we uncover the first "bug" as part of
enforcing interfaces: stream_out() wasn't implemented on localpeer!
This isn't technically a bug since the repo isn't advertising the
stream capability, so clients shouldn't be attempting to call it.
But I don't think there's a good reason why this is the case.
We implement a dummy method to satisfy the interface requriements.
We can make localpeer instances streamable as a future enhancement.
# no-check-commit
Differential Revision: https://phab.mercurial-scm.org/D335
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 16:47:25 -0700] rev 33823
repository: implement generic capability methods on peer class
These methods are part of the peer interface, are generic, and can
be implemented in terms of other members of the peer interface. So we
implement them on the peer base class as a convenience.
The implementation is essentially copied from peer.py. The code
in peer.py will eventually be deleted.
Differential Revision: https://phab.mercurial-scm.org/D334
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 13 Aug 2017 11:04:42 -0700] rev 33822
repository: formalize wire protocol interface
There are a well-defined set of commands constituting the wire
protocol. Interaction with these and methods for calling them in
batches are exposed via methods on peer instances.
Let's formalize support for these features in abstract classes.
The command parts come from the existing wireproto.wirepeer class.
The batch methods come from peer.peerrepository.
Ample documentation has been added as part of defining the interfaces.
# no-check-commit
Differential Revision: https://phab.mercurial-scm.org/D333
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