Pulkit Goyal <7895pulkit@gmail.com> [Fri, 30 Mar 2018 12:50:06 -0700] rev 37203
infinitepush: delete the non-forward-move flag for hg push
Differential Revision: https://phab.mercurial-scm.org/D2955
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Mar 2018 19:23:10 +0530] rev 37202
infinitepush: drop the wrapping of update command on client side
The extension wraps update command to client side to add functionality to pull
and checkout to a revision if it does not present locally. There is a twist to
that, only changesets which can resolve to remotenames can be pulled using this.
Differential Revision: https://phab.mercurial-scm.org/D2954
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 30 Mar 2018 12:49:50 -0700] rev 37201
infinitepush: delete infinitepushcommands.py and related tests
This patch drops infinitepushcommands.py and the tests which were related to the
command `debugfillinfinitepushmetadata` introduced in the commit.
The patch also drops a config option which was related to
debuginfinitepushmetadata command.
Differential Revision: https://phab.mercurial-scm.org/D2953
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 27 Mar 2018 18:04:05 +0530] rev 37200
infinitepush: delete infinitepush.fillmetadatabranchpattern config option
This patch deletes the config option infinitepush.fillmetadatabranchpattern
which if set to true sets a background process which will save metadata in
infinitepush index.
This series is meant to have a state where we can use it for CI purposes.
Differential Revision: https://phab.mercurial-scm.org/D2952
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 15:49:46 +0530] rev 37199
infinitepush: drop the `--to` flag to push and use `-B` instead
The extension added a `--to` flag to specify the bookmark to which revs should
be pushed. This patch deletes that flag and instead uses the `-B` flag. After
this patch, bookmark passed as `-B` is parsed and if it matches the infinitepush
bookmark pattern, we consider that push as infinitepush.
This is still not the best of what we can do. Later patches in the series will
drop the use of `-B` flag and will instead handle things at bookmark bundle2
part. Plugging these logic to bookmark bundle2 part will also get rid of the
scratchbranchparttype bundle2 part.
Differential Revision: https://phab.mercurial-scm.org/D2108
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 14:16:03 +0530] rev 37198
infinitepush: drop the `--create` flag to push command
The extension added a `--create` flag for creating a new bookmark on the
bundlestore. This patch changes the bahviour to create a bookmark if it does not
exists and removes the requirement of the `--create` and then drop the logic
around the `--create` flag.
Tests are changed to drop the usage of `--create` flag.
Differential Revision: https://phab.mercurial-scm.org/D2107
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 14:02:03 +0530] rev 37197
infinitepush: drop logic related to treemanifest extension
treemanifest is another facebook's extension which is not in core. Let's drop
the logic related to infinitepush extension which is now ported to core.
Differential Revision: https://phab.mercurial-scm.org/D2106
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 13:56:09 +0530] rev 37196
infinitepush: drop hack related to --to, --create flags of remotenames-ext
The remotenames extension has --to, --create. --allow-anon flags which won't be
ported to core. This patch drops the hack which fixes the interaction with
remotenames-ext during push.
In upcoming patches, --to and --create extensions will be removed from
infinitepush also.
Differential Revision: https://phab.mercurial-scm.org/D2105
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 13:50:16 +0530] rev 37195
infinitepush: drop error handling while pushing to svn server
This is something which is internal to Facebook and we don't want in core.
Differential Revision: https://phab.mercurial-scm.org/D2104
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 13:36:50 +0530] rev 37194
infinitepush: drop `--list-remote`, `--remote-path` flags to bookmark cmd
The extension adds these two flags to list remote bookmarks using the `hg
bookmark` command. These are not required in core currently and needs some
discussion before getting them in, so let's drop them for now. This makes us
deleting the wrapping of `hg bookmark` command on client side.
The end goal here is to have minimal or no wrapping at client side.
Differential Revision: https://phab.mercurial-scm.org/D2103
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 08 Feb 2018 17:27:47 +0530] rev 37193
infinitepush: drop the scratchbookmarksparttype bundle2 part
The scratchbookmarksparttype bundle2 part was used in backupcommands.py which we
deleted in an earlier changeset. We don't need this part anymore. Moreover we
now have bookmarks bundle2 part in core which we can use. This patch also drops
the related encoding and decoding functions.
Differential Revision: https://phab.mercurial-scm.org/D2102
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 08 Feb 2018 17:18:28 +0530] rev 37192
infinitepush: remove wrapping around bundle2._addpartsfromopts()
This wrapping around bundle2._addpartsfromopts() was added by me while hacking
on an alternate way to mark a push as infinitepush or not. However the wrapping
is wrong as the push command does not go through the code path which was wrapped
on the client side.
Differential Revision: https://phab.mercurial-scm.org/D2101
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 08 Feb 2018 17:12:53 +0530] rev 37191
infinitepush: delete the bundle2 part ordering related to pushrebase
pushrebase is another Facebook extension which does not live in core yet. So
let's remove the logic which make sures infinitepush part is moved before the
pushrebase one.
Differential Revision: https://phab.mercurial-scm.org/D2100
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 08 Feb 2018 17:09:24 +0530] rev 37190
infinitepush: delete the hack to load the extension after remotenames
The remotenames extension which circumvents the default push implementation
lives outside the core, so let's delete logic related to loading of extension on
the basis of remotenames ext.
Differential Revision: https://phab.mercurial-scm.org/D2099
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 03 Feb 2018 17:59:49 +0530] rev 37189
infinitepush: drop the logic related to inhibit extension
The inhibit extension lives in hg-experimental and is not a core extension.
Differential Revision: https://phab.mercurial-scm.org/D2098
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 03 Feb 2018 17:54:55 +0530] rev 37188
infinitepush: remove backupcommands.py
This file contains command pushbackup and pullbackup which are used to store
things to infinitepush.
This is an advanced functionality which we don't require as of now. Also this
uses shareutil.py from fb-hgext/ which is not there in core. Therefore this
patch deletes the file and the config option which belongs to the backup thing.
If we need this functionality in future, we can always move this file back.
Differential Revision: https://phab.mercurial-scm.org/D2097
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 09 Feb 2018 13:39:15 +0530] rev 37187
infinitepush: move the extension to core from fb-hgext
This patch moves the infinitepush extension from fb-hgext to core. The
extension is used to store incoming bundles during a push in bundlestore rather
than applying them to the revlog.
The extension was copied from the repository revision at
f27f094e91553d3cae5167c0b1c42ae940f888d5 and following changes were made:
* added `from __future__ import absolute_import` where missing
* fixed module imports to follow the core style
* minor fixes for test-check-code.t
* registered the configs
* adding the testedwith value to match core's convention
* removed double newlines to make test-check-commit.t happy
* added one line doc about extension and marked it as experimental
Only one test file test-infinitepush-bundlestore.t is moved to core and
following changes are made to file:
* remove dependency of library.sh
* split the tests into two tests i.e. test-infinitepush.t and
test-infinitepush-bundlestore.t
* removed testing related to other facebook's extensions pushrebase, inhibit,
fbamend
library-infinitepush.sh is also copied from fb-hgext from the same revision and
following changes are made:
* change the path to infinitepush extension as it's in core with this patch
* removed sql handling from the file as we are not testing that initially
Currently at this revision, test-check-module-imports.t does not pass as there
is import of a module from fb/hgext in one the of the file which will be removed
in the next patch.
This extension right now has a lot of things which we don't require in core like
`--to`, `--create` flags to `hg bookmark`, logic related to remotenames
extension and another facebook's extensions, custom bundle2parts which can be
prevented by using bookmarks bundle part and also logic related to sql store
which is probably we don't want initially.
The next patches in this series will remove all the unwanted and unrequired
things from the extension and will make this a nice one.
The end goal is to have a very lighweight extension with no or very less
wrapping on the client side.
Differential Revision: https://phab.mercurial-scm.org/D2096
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Mar 2018 11:15:58 -0700] rev 37186
narrow: use repo.local() instead of isinstance()
Differential Revision: https://phab.mercurial-scm.org/D2973
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 30 Mar 2018 11:33:21 -0700] rev 37185
tests: add zope.interface to clang-format ignore list
Differential Revision: https://phab.mercurial-scm.org/D2975
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 30 Mar 2018 11:35:17 -0700] rev 37184
contrib: rename clang-format-blacklist to clang-format-ignorelist
"blacklist" is racially charged. Let's rename it to something
that isn't.
Differential Revision: https://phab.mercurial-scm.org/D2974
Danny Hooper <hooper@google.com> [Sat, 03 Mar 2018 14:08:44 -0800] rev 37183
fix: new extension for automatically modifying file contents
This change implements most of the corresponding proposal as discussed at the
4.4 and 4.6 sprints: https://www.mercurial-scm.org/wiki/AutomaticFormattingPlan
This change notably does not include parallel execution of the formatter/fixer
tools. It does allow for implementing that without affecting other areas of the
code.
I believe the test coverage to be good, but this is a hotbed of corner cases.
Differential Revision: https://phab.mercurial-scm.org/D2897
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 30 Mar 2018 11:11:42 -0700] rev 37182
tests: ignore zope packages when running pyflakes
Differential Revision: https://phab.mercurial-scm.org/D2972
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 21 Mar 2018 19:48:36 -0700] rev 37181
repository: define interface for local repositories
Per discussions on the mailing list and at the 4.4 and 4.6 sprints,
we want to start defining interfaces for local repository primitives
so that we a) have a better idea of what the formal interface for
various types is b) can more easily introduce alternate implementations
of various components (e.g. in Rust).
We have previously implemented interfaces that declare the peer and
wire protocol APIs using the abc module.
This commit introduces a monolithic interface for the localrepository
class. It uses zope.interface - not abc - for defining and declaring
the interface.
The newly defined "completelocalrepository" interface is objectively
horrible. It is based on what is actually in localrepository and
doesn't represent a reasonable interface definition IMO. There's lots
of... unwanted garbage in the interface. In other words, it reflects
the horrible state of the localrepository "god object." But this is
fine: a goal of this commit is to get the interface defined so that
we have an interface. Future commits can refactor the interface
into sub-interfaces, remove unwanted public attributes, etc.
I attempted to define reasonable docstrings for the various interface
members. But there are so many of them and I didn't know what some are
used for. So I was lazy in a number of places and didn't write
docstrings or detailed usage docs.
Also, the members of the interface are defined in the order they are
declared in localrepo.py. This revealed that the grouping of things
in localrepo.py is... odd.
The localrepository class now declares that it implements our newly
defined interface. Unlike abc, zope.interface doesn't check interface
conformance at type creation time (abc uses __metaclass__ magic to
validate interface conformance when a type is created - usually at
module import time). It does provide some functions for validating
class and object conformance with declared interfaces. We add these
checks to test-check-interfaces.py. We /could/ validate at run-time.
But we hold off for now. (I'm a bit scared of doing that because of
the various ways extensions monkeypatch repo instances.)
After this commit, test-check-interfaces.py will fail if the set of
public attributes on the localrepository class or instances change
without corresponding updates to the interface. This is by design.
Differential Revision: https://phab.mercurial-scm.org/D2933
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
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
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
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