Gregory Szorc <gregory.szorc@gmail.com> [Fri, 30 Mar 2018 11:33:21 -0700] rev 37187
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 37186
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 37185
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 37184
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 37183
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 37182
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 37181
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 37180
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 37179
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 37178
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 37177
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 37176
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 37175
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 37174
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 37173
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 37172
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
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 11:44:33 +0100] rev 37171
streamclonebundle: add a test for stream clone bundle v2
Differential Revision: https://phab.mercurial-scm.org/D1956
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 11:10:55 +0100] rev 37170
bundlespec: add support for some variants
This way the stream v2 bundle spec can disable the changegroup part while
enabling the stream v2 part.
Differential Revision: https://phab.mercurial-scm.org/D1955
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 11:09:20 +0100] rev 37169
bundle: add the possibility to bundle a stream v2 part
Differential Revision: https://phab.mercurial-scm.org/D1954
Boris Feld <boris.feld@octobus.net> [Wed, 31 Jan 2018 10:55:15 +0100] rev 37168
streambundlev2: add a new test-file
Add the new test file in a separate changeset before supporting the new format
so we better see the differences.
Differential Revision: https://phab.mercurial-scm.org/D1953
Boris Feld <boris.feld@octobus.net> [Fri, 30 Mar 2018 12:43:57 +0200] rev 37167
bundlespec: move computing the bundle contentops in parsebundlespec
We will introduce a new bundlespec for stream bundle which will influence the
contentops.
Differential Revision: https://phab.mercurial-scm.org/D1952
Boris Feld <boris.feld@octobus.net> [Fri, 30 Mar 2018 12:43:08 +0200] rev 37166
bundlespec: introduce an attr-based class for bundlespec
We will add support of contentops in the next patch, introduce a class instead
of returning a 4-items tuple.
Differential Revision: https://phab.mercurial-scm.org/D2971
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Mar 2018 20:43:55 +0900] rev 37165
templater: factor out unwrapastype() from evalastype()
So ParseError of unwrapastype() can be caught reliably.
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Mar 2018 20:34:12 +0900] rev 37164
templater: extract unwrapinteger() function from evalinteger()
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Mar 2018 21:03:21 +0900] rev 37163
templater: extract type conversion from evalfuncarg()
Needed by the subsequent patches.
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Mar 2018 20:23:55 +0900] rev 37162
templater: drop bool support from evalastype()
Future patches will split evalastype() into two functions, evalrawexp()
and unwrapastype(), so we can catch the exception of type conversion.
# evaluating function may bubble up inner ParseError
thing = evalrawexp(context, mapping, arg)
try:
return unwrapastype(context, thing)
except ParseError:
# add hint and reraise
However, evalboolean() can't be factored out in this way since it has to
process boolean-like symbols as non keyword. Fortunately, it's unlikely
that we'll need a general type converter supporting bool, so this patch
drops it from the table.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:13:06 +0900] rev 37161
templater: do not use stringify() to concatenate flattened template output
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:04:20 +0900] rev 37160
templateutil: reimplement stringify() using flatten()
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:00:54 +0900] rev 37159
templateutil: move flatten() from templater
It's the same kind of utility as stringify().
Connor Sheehan <sheehan@mozilla.com> [Tue, 27 Mar 2018 11:01:13 -0400] rev 37158
stringutil: move person function from templatefilters
Move the person function from template filters to the stringutil
module, so it can be reused in the mailmap template function.
Differential Revision: https://phab.mercurial-scm.org/D2960
Connor Sheehan <sheehan@mozilla.com> [Thu, 22 Mar 2018 09:48:22 -0400] rev 37157
stringutil: add isauthorwellformed function
The regular expression for this function formerly lived at
https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/hghooks/mozhghooks/author_format.py#l13
Differential Revision: https://phab.mercurial-scm.org/D2959
Matt Harbison <matt_harbison@yahoo.com> [Sat, 17 Mar 2018 02:37:46 -0400] rev 37156
test-lfs-test-server: add a testcase for `hg serve`
I haven't figured out yet how to make the authentication checks work for a
specific list of users, so the 'web.allow-push' list is wildcarded. (It appears
that the client doesn't react to a 401 by sending authentication data, which may
be caused in part by not having all of the headers in httpbasicauthhandler's
http_error_auth_reqed(), compared to a run of test-http.t. But in any case, we
should probably have a separate set of tests for various authentication
scenarios. As it is, without the wildcard, no push access is granted.)
There are several deviations from the `lfs-test-server` case:
- `hg serve` emits a Server header. I think Gregory indicated that this isn't
easily suppressed.
- `hg serve` names the "basic" transfer handler in the Batch API response. Not
having to specify it was for backwards compatability, so this seems like the
right thing to do. (`lfs-test-server` doesn't name it, whether it was
explicitly requested by the client or not.)
- PUT status for a newly created file is 201, per RFC-2616 [1]. The Basic
Transfer API [2] shows an example upload transcript with a 200 response. It
doesn't make much sense to re-upload a file (unless it is corrupt) in an
example, but I wouldn't be surprised if some other implementations also
expect 200 because of this. But the RFC says MUST use 201 for creation.
- The Content-Type for the file transfers is "application/octet-stream", like
the sample transcript (though I don't see it explicitly called out in the
text elsewhere). Using "text/plain" seems clearly wrong.
- `lfs-test-server` isn't removing the action property and sending back an
error code like the spec calls out when a file is missing or corrupt. Doing
so on the `hg serve` side reveals a bug in our client code when handling the
response- it indicates the remote file is missing instead of corrupt around
line 452.
I'll probably glob over the Content-Length differences once this settles down.
Prior to the recent hgweb refactoring, the Batch API response was using chunked
encodings instead.
Back to the RFC, I have no idea if the python framework handles the "MUST NOT
ignore any Content-* (e.g. Content-Range) headers that it does not understand or
implement and MUST return a 501" for a PUT request.
[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads