Wed, 21 Mar 2018 18:32:47 -0700 setup: register zope.interface packages and compile C extension
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 18:32:47 -0700] rev 37180
setup: register zope.interface packages and compile C extension With this change, we should be able to use zope.interface in core! Differential Revision: https://phab.mercurial-scm.org/D2932
Wed, 21 Mar 2018 18:13:40 -0700 thirdparty: allow zope.interface.advice to be lazily imported
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 18:13:40 -0700] rev 37179
thirdparty: allow zope.interface.advice to be lazily imported The symbol from this module is only used in functions. Let's access that symbol through its imported module so importing zope.interface.advice can be lazy. Differential Revision: https://phab.mercurial-scm.org/D2931
Wed, 21 Mar 2018 19:52:30 -0700 thirdparty: port zope.interface to relative imports
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 19:52:30 -0700] rev 37178
thirdparty: port zope.interface to relative imports By using relative imports, we're guaranteed to get modules vendored with Mercurial rather than other random modules that might be in sys.path. My editor strips trailing whitespace on save. So some minor source code cleanup was also performed as part of this commit. # no-check-commit because some modified lines have double newlines Differential Revision: https://phab.mercurial-scm.org/D2930
Wed, 21 Mar 2018 19:49:07 -0700 thirdparty: don't make zope a namespace package
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
Wed, 21 Mar 2018 19:48:50 -0700 thirdparty: vendor zope.interface 4.4.3
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
Thu, 29 Mar 2018 23:05:41 -0700 context: set repo property in basectx
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
Thu, 29 Mar 2018 22:51:45 -0700 context: move reuse of context object to repo.__getitem__ (API)
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
Thu, 29 Mar 2018 22:22:51 -0700 memctx: create parent contexts using "repo[p]" syntax
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
Thu, 29 Mar 2018 21:29:15 -0700 context: avoid using a context object as a changeid
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
Thu, 29 Mar 2018 21:15:40 -0700 context: remove unwanted assignments in basectx.__new__() (API)
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
Wed, 31 Jan 2018 17:15:44 +0100 streamclonebundle: make sure we accept new stream clone bundle spec
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
Wed, 31 Jan 2018 11:44:33 +0100 streamclonebundle: add a test for stream clone bundle v2
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 11:44:33 +0100] rev 37169
streamclonebundle: add a test for stream clone bundle v2 Differential Revision: https://phab.mercurial-scm.org/D1956
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip