Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 19:49:07 -0700] rev 37177
thirdparty: don't make zope a namespace package
There are a gazillion zope.* packages in the wild. So zope/__init__.py
needs to be a namespace package. But in Mercurial, we have 1 zope
package. And even if we had multiple packages, they'd all be in
thirdparty/zope/. So we don't need a namespace package.
Differential Revision: https://phab.mercurial-scm.org/D2929
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 19:48:50 -0700] rev 37176
thirdparty: vendor zope.interface 4.4.3
I've been trying to formalize interfaces for various components
of Mercurial. So far, we've been using the "abc" package. This
package is "good enough" for a lot of tasks. But it quickly
falls over. For example, if you declare an @abc.abstractproperty,
you must implement that attribute with a @property or the class
compile time checking performed by abc will complain. This often
forces you to implement dumb @property wrappers to return a
_ prefixed attribute of the sane name. That's ugly.
I've also wanted to implement automated checking that classes
conform to various interfaces and don't expose other "public"
attributes.
After doing a bit of research and asking around, the general
consensus seems to be that zope.interface is the best package for
doing interface-based programming in Python. It has built-in
support for verifying classes and objects conform to interfaces.
It allows an interface's properties to be defined during __init__.
There's even an "adapter registry" that allow you to register
interfaces and look up which classes implement them. That could
potentially be useful for places where our custom registry.py
modules currently facilitates central registrations, but at a
type level. Imagine extensions providing alternate implementations
of things like the local repository interface to allow opening
repositories with custom requirements.
Anyway, this commit vendors zope.interface 4.4.3. The contents of
the source tarball have been copied into mercurial/thirdparty/zope/
without modifications.
Test modules have been removed because they are not interesting
to us.
The LICENSE.txt file has been copied so it lives next to the
source.
The Python modules don't use relative imports. zope/__init__.py
defines a namespace package. So we'll need to modify the source
code before this package is usable inside Mercurial. This will
be done in subsequent commits.
# no-check-commit for various style failures
Differential Revision: https://phab.mercurial-scm.org/D2928
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 23:05:41 -0700] rev 37175
context: set repo property in basectx
It seems like a good practice to call the super constructor. Let's
start by passing the repo along to basectx so it can assign it to a
private attribute. We should perhaps pass the rev and node along as
well, but that requires more work before it can be done.
Differential Revision: https://phab.mercurial-scm.org/D2970
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 22:51:45 -0700] rev 37174
context: move reuse of context object to repo.__getitem__ (API)
As an example of how weird the basectx.__new__ is: whenever you create
a workingctx, basectx.__new__ gets called first. Since our __new__ has
a "changeid" argument as second parameter, when create the
workingctx(repo, text="blah"), the text gets bound to
"changeid". Since a string isn't a basectx, our __new__ ends up not
doing anything funny, but that's still very confusing code.
Another case is metadataonlyctx.__new__(), which I think exists in
order to prevent metadataonlyctx.__init__'s third argument
(originalctx) from being interpreted as a changeid in
basectx.__new__(), thereby getting reused.
Let's move this to repo.__getitem__ instead, where it will be pretty
obvious what the code does.
After this patch, changectx(ctx) will be an error (it will fail when
trying to see if it's a 20-byte string).
Differential Revision: https://phab.mercurial-scm.org/D2969
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 22:22:51 -0700] rev 37173
memctx: create parent contexts using "repo[p]" syntax
I want to reduce dependence on basectx.__new__() and move that code
over to repo.__getitem__().
Differential Revision: https://phab.mercurial-scm.org/D2968
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 21:29:15 -0700] rev 37172
context: avoid using a context object as a changeid
I find it misleading to pass changeid=changectx. It currently works to
do that because there's weird (IMO) handling of it in
basectx.__new__. I'm planning on removing that code. Passing changeid
as "changeid" and context as "context" makes it more readable.
Note that the documentation of filectx.__init__ doesn't even seem to
be aware that a changeid can be a context ("changeset revision, node,
or tag").
Differential Revision: https://phab.mercurial-scm.org/D2967
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Mar 2018 21:15:40 -0700] rev 37171
context: remove unwanted assignments in basectx.__new__() (API)
The two subclasses in core apparently didn't trust __new__() to do the
job anyway (they both reassigned all the properties after).
Differential Revision: https://phab.mercurial-scm.org/D2966
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 17:15:44 +0100] rev 37170
streamclonebundle: make sure we accept new stream clone bundle spec
When asked specifically, the code do a sanity check on the clone bundle to
ensure it's a stream bundle. As we introduced a new stream bundle spec, update
the logic to support it.
With this final changeset, we can now announce safely a stream v2 clone bundle
and old clients would not crash trying to process it.
This changeset address the last comment from Gregory Szorc on the stream v2
bundle series.
Differential Revision: https://phab.mercurial-scm.org/D1957