wireproto: mark SSHv2 as a version 1 transport The version component is used for filtering/routing wire protocol commands to their proper handler. The actual version 2 of the wire protocol commands will use a different encoding of responses. We already have tests using the version 2 SSH transport and version 2 of the wire protocol commands won't be implemented atomically. This commit marks the SSHv2 transport as version 1 so it will still invoke the version 1 commands. Once the commands are all implemented in version 2, we can restore its proper behavior. Some tests had to be disabled as a result of this change. Differential Revision: https://phab.mercurial-scm.org/D2981

wireproto: stop aliasing wire protocol types (API) We generally shy away from aliasing module symbols. I think I was keeping this around for API compatibility. We've already made tons of other API breaks in the wire protocol code this release. What's one more? .. api:: ``wireproto`` module no longer re-exports various types used to define responses to wire protocol commands. Access these types from the ``wireprototypes`` module. Differential Revision: https://phab.mercurial-scm.org/D2979

wireproto: use CBOR for command requests Now that we're using CBOR in the new wire protocol, let's convert command requests to it. Before I wrote this patch and was even thinking about CBOR, I was thinking about how commands should be issued and came to the conclusion that we didn't need separate frames to represent the command name from its arguments. I already had a partially completed patch prepared to merge the frames. But with CBOR, it makes the implementation a bit simpler because we don't need to roll our own serialization. The changes here are a bit invasive. I tried to split this into multiple commits to make it easier to review. But it was just too hard. * "command name" and "command argument" frames have been collapsed into a "command request" frame. * The flags for this new frame are totally different. * Frame processing has been overhauled to reflect the new order of things. * Test fallout was significant. A handful of tests were removed. Altogether, I think the new code is simpler. We don't have complicated state around receiving commands. We're either receiving command request frames or command data frames. We /could/ potentially collapse command data frames into command request frames. Although I'd have to think a bit more about this before I do it. Differential Revision: https://phab.mercurial-scm.org/D2951

wireproto: define frame to represent progress updates Today, a long-running operation on a server may run without any sign of progress on the client. This can lead to the conclusion that the server has hung or the connection has dropped. In fact, connections can and do time out due to inactivity. And a long-running server operation can result in the connection dropping prematurely because no data is being sent! While we're inventing the new wire protocol, let's provide a mechanism for communicating progress on potentially expensive server-side events. We introduce a new frame type that conveys "progress" updates. This frame type essentially holds the data required to formulate a ``ui.progress()`` call. We only define the frame right now. Implementing it will be a bit of work since there is no analog to progress frames in the existing wire protocol. We'll need to teach the ui object to write to the wire protocol, etc. The use of a CBOR map may seem wasteful, as this will encode key names in every frame. This *is* wasteful. However, maps are extensible. And the intent is to always use compression via streams. Compression will make the overhead negligible since repeated strings will be mostly eliminated over the wire. Differential Revision: https://phab.mercurial-scm.org/D2902

wireproto: syntax for encoding CBOR into frames We just vendored a library for encoding and decoding the CBOR data format. While the intent of that vendor was to support state files, CBOR is really a nice data format. It is extensible and compact. I've been feeling dirty inventing my own data formats for frame payloads. While custom formats can always beat out a generic format, there is a cost to be paid in terms of implementation, comprehension, etc. CBOR is compact enough that I'm not too worried about efficiency loss. I think the benefits of using a standardized format outweigh rolling our own formats. So I plan to make heavy use of CBOR in the wire protocol going forward. This commit introduces support for encoding CBOR data in frame payloads to our function to make a frame from a human string. We do need to employ some low-level Python code in order to evaluate a string as a Python expression. But other than that, this should hopefully be pretty straightforward. Unit tests for this function have been added. Differential Revision: https://phab.mercurial-scm.org/D2948

wireproto: explicit API to create outgoing streams It is better to create outgoing streams through the reactor so the reactor knows about what streams are active and can track them accordingly. Test output changes slightly because frames from subsequent responses no longer have the "stream begin" stream flag set because the stream is now used across all responses. Differential Revision: https://phab.mercurial-scm.org/D2947

wireproto: add streams to frame-based protocol Previously, the frame-based protocol was just a series of frames, with each frame associated with a request ID. In order to scale the protocol, we'll want to enable the use of compression. While it is possible to enable compression at the socket/pipe level, this has its disadvantages. The big one is it undermines the point of frames being standalone, atomic units that can be read and written: if you add compression above the framing protocol, you are back to having a stream-based protocol as opposed to something frame-based. So in order to preserve frames, compression needs to occur at the frame payload level. Compressing each frame's payload individually will limit compression ratios because the window size of the compressor will be limited by the max frame size, which is 32-64kb as currently defined. It will also add CPU overhead, as it is more efficient for compressors to operate on fewer, larger blocks of data than more, smaller blocks. So compressing each frame independently is out. This means we need to compress each frame's payload as if it is part of a larger stream. The simplest approach is to have 1 stream per connection. This could certainly work. However, it has disadvantages (documented below). We could also have 1 stream per RPC/command invocation. (This is the model HTTP/2 goes with.) This also has disadvantages. The main disadvantage to one global stream is that it has the very real potential to create CPU bottlenecks doing compression. Networks are only getting faster and the performance of single CPU cores has been relatively flat. Newer compression formats like zstandard offer better CPU cycle efficiency than predecessors like zlib. But it still all too common to saturate your CPU with compression overhead long before you saturate the network pipe. The main disadvantage with streams per request is that you can't reap the benefits of the compression context for multiple requests. For example, if you send 1000 RPC requests (or HTTP/2 requests for that matter), the response to each would have its own compression context. The overall size of the raw responses would be larger because compression contexts wouldn't be able to reference data from another request or response. The approach for streams as implemented in this commit is to support N streams per connection and for streams to potentially span requests and responses. As explained by the added internals docs, this facilitates servers and clients delegating independent streams and compression to independent threads / CPU cores. This helps alleviate the CPU bottleneck of compression. This design also allows compression contexts to be reused across requests/responses. This can result in improved compression ratios and less overhead for compressors and decompressors having to build new contexts. Another feature that was defined was the ability for individual frames within a stream to declare whether that individual frame's payload uses the content encoding (read: compression) defined by the stream. The idea here is that some servers may serve data from a combination of caches and dynamic resolution. Data coming from caches may be pre-compressed. We want to facilitate servers being able to essentially stream bytes from caches to the wire with minimal overhead. Being able to mix and match with frames are compressed within a stream enables these types of advanced server functionality. This commit defines the new streams mechanism. Basic code for supporting streams in frames has been added. But that code is seriously lacking and doesn't fully conform to the defined protocol. For example, we don't close any streams. And support for content encoding within streams is not yet implemented. The change was rather invasive and I didn't think it would be reasonable to implement the entire feature in a single commit. For the record, I would have loved to reuse an existing multiplexing protocol to build the new wire protocol on top of. However, I couldn't find a protocol that offers the performance and scaling characteristics that I desired. Namely, it should support multiple compression contexts to facilitate scaling out to multiple CPU cores and compression contexts should be able to live longer than single RPC requests. HTTP/2 *almost* fits the bill. But the semantics of HTTP message exchange state that streams can only live for a single request-response. We /could/ tunnel on top of HTTP/2 streams and frames with HEADER and DATA frames. But there's no guarantee that HTTP/2 libraries and proxies would allow us to use HTTP/2 streams and frames without the HTTP message exchange semantics defined in RFC 7540 Section 8. Other RPC protocols like gRPC tunnel are built on top of HTTP/2 and thus preserve its semantics of stream per RPC invocation. Even QUIC does this. We could attempt to invent a higher-level stream that spans HTTP/2 streams. But this would be violating HTTP/2 because there is no guarantee that HTTP/2 streams are routed to the same server. The best we can do - which is what this protocol does - is shoehorn all request and response data into a single HTTP message and create streams within. At that point, we've defined a Content-Type in HTTP parlance. It just so happens our media type can also work as a standalone, stream-based protocol, without leaning on HTTP or similar protocol. Differential Revision: https://phab.mercurial-scm.org/D2907

Added signature for changeset 7de7bd407251

Added tag 4.5.3 for changeset 7de7bd407251

wireproto: start to associate frame generation with a stream An upcoming commit will introduce "streams" into the frame-based wire protocol. In preparation for this invasive change, we introduce a basic "stream" class and have all operations that create frames also operate alongside a stream instance. Differential Revision: https://phab.mercurial-scm.org/D2906

tests: fix duplicate and failing test There were two "testconflictingrequestid" methods. Naturally this isn't an error in Python. And by our luck, the test was failing. So we rename the test and fix it to pass. As part of this, _sendsingleframe() now takes a frame, not a string describing the frame. This is better because action at a distance can be confusing. Differential Revision: https://phab.mercurial-scm.org/D2950

debugcommands: drop offset and length from debugindex by default These fields are an implementation detail of revlog storage. As such, they are not part of the generic storage "index" interface and shouldn't be displayed by default. Because we don't have another way to display these fields, we've retained support for printing these fields via --verbose. Yes, I know we should probably be doing all this formatting using modern formatting/templater APIs. I didn't feel like scope bloating this patch. Differential Revision: https://phab.mercurial-scm.org/D3028

debugcommands: drop base revision from debugindex Revlog index data consists of generic index metadata that will likely be implemented across all storage engines and revlog-specifc metadata. Most tests printing index data only care about the generic fields. This commit drops the printing of the base revision from `hg debugindex`. This value is an implementation detail of revlogs / delta chains. If tests are interested in verifying this implementation detail, `hg debugdeltachain` is a better command. Most tests were skipping over this field anyway. Tests that weren't looked like they were newer. So my guess is we forgot to make them skip the field to match the style of the older tests. This reinforces my belief that the base revision is not worth having in `hg debugindex`. Differential Revision: https://phab.mercurial-scm.org/D3027

tests: use debugdeltachain where appropriate Some tests are verifying delta chain type things. This metadata has more to do with a revlog implementation details than index data, which is theoretically generic. This commit ports some tests to `hg debugdeltachain`, as it is the more appropriate debug command for looking at delta metadata. Differential Revision: https://phab.mercurial-scm.org/D3026

tests: don't use revlog paths in tests Debug commands operating on revlogs don't need the full revlog path: they can accept the relative path to a tracked file or use -c/-m to specify a changelog or manifest. Not using the revlog path makes tests more resilient to cases where revlogs aren't being used for storage. Differential Revision: https://phab.mercurial-scm.org/D3025

templater: define interface for objects requiring unwrapvalue() unwrapvalue() is changed to not return a lazy bytes generator for "wrapped" types because I want to define the tovalue() interface as such. It's a baby step to unify unwrapvalue() and _unwrapvalue().

templater: extract private function to evaluate generator to byte string

templater: pass (context, mapping) down to unwrapvalue() The same reason as why I made unwraphybrid() take a (context, mapping) pair.

templater: drop unneeded generator from mappable object Per the definition of the show() interface, it can return a bytes.

templater: mark .gen as a private attribute

templatekw: do not directly call .gen

templater: define interface for objects requiring unwraphybrid() Prepares for introducing another hybrid-like data type. show() takes context as an argument so a wrapper class may render its items by pre-configured template: def show(self, context, mapping): return (context.expand(self._tmpl, mapping + lm) for lm in self._mappings)

templater: pass (context, mapping) down to unwraphybrid() See the subsequent patches for why. I initially thought it would be wrong to pass a mapping to flatten() and stringify() since these functions may be applied to a tree of generators, where each node should be bound to the mapping when it was evaluated. But, actually that isn't a problem. If an intermediate node has to override a mapping dict, it can do on unwraphybrid() and yield "unwrapped" generator of byte strings: "{f(g(v))}" # literal template example. ^^^^ # g() want to override a mapping, so it returns a wrapped # object 'G{V}' with partial mapping 'lm' attached. ^^^^^^^ # f() stringifies 'G{V}', starting from a mapping 'm'. # when unwrapping 'G{}', it updates 'm' with 'lm', and # passes it to 'V'. This structure is important for the formatter (and the hgweb) to build a static template keyword, which can't access a mapping dict until evaluation phase.

scmutil: add method for looking up a context given a revision symbol changectx's constructor currently supports a mix if inputs: * integer revnums * binary nodeids * '.', 'tip', 'null' * stringified revnums * namespaced identifiers (e.g. bookmarks and tags) * hex nodeids * partial hex nodeids The first two are always internal [1]. The other five can be specified by the user. The third type ('.', 'tip', 'null') often comes from either the user or internal callers. We probably have some internal callers that pass hex nodeids too, perhaps even partial ones (histedit?). There are only a few callers that pass user-supplied strings: revsets.stringset, peer.lookup, webutil.changeidctx, and maybe one or two more. Supporting this mix of things in the constructor is convenient, but a bit strange, IMO. For example, if repo[node] is given a node that's not in the repo, it will first check if it's bookmark etc before raising an exception. Of course, the risk of it being a bookmark is extremely small, but it just feels ugly. Also, a problem with having this code in the constructor (whether it supports a mix of types or not) is that it's harder to override (I'd like to override it, and that's how this series started). This patch starts moving out the handling of user-supplied strings by introducing scmutil.revsymbol(). So far, that just checks that the input is indeed a string, and then delegates to repo[symbol]. The patch also calls it from revsets.stringset to prove that it works. [1] Well, you probably can enter a 20-byte binary nodeid on the command line, but I don't think we should care to preserve support for that. Differential Revision: https://phab.mercurial-scm.org/D3024

narrow: add trailing slash to dir earlier for debug{revlog,index,data} The treemanifest code internally uses trailing slashes on directories (except for the root directory, which is an empty string). We should make sure we pass in directories with trailing slashes when we work with the treemanifest code. For some reason, I seem to have decided to be nice to the callers instead in 49c583ca48c4 (treemanifest: add --dir option to debug{revlog,data,index}, 2015-04-12). Let's fix that and pay the cost of fixing up the directory name close close to where we get it from the user. Differential Revision: https://phab.mercurial-scm.org/D3032

addremove: remove dry_run, similarity from scmutil.addremove (API) Differential Revision: https://phab.mercurial-scm.org/D3000

histedit: make errror message translatable This is a follow up patch to https://phab.mercurial-scm.org/D2394 As suggested by Yuya, this patch makes the error message translatable Differential Revision: https://phab.mercurial-scm.org/D3031

context: drop support for changeid='' (API) Since the previous commit, there seem to be no users who pass '' to repo.__getitem__, so let's drop support for it. It may seem like a small cost to keep support for it, but I've spent time being confused by it twice already. Differential Revision: https://phab.mercurial-scm.org/D3021

subrepo: use repo['.'] instead of repo[''] The "state" value (a revision) passed to abstractsubrepo.phase() can be '' to represent the currently checked out revisions. Let's convert that to the more common '.'. I think this is the last of use of repo['.'] in core. Differential Revision: https://phab.mercurial-scm.org/D3019

children: use repo['.'] instead of repo[''] Differential Revision: https://phab.mercurial-scm.org/D3020

revset: drop support for '' as alias for '.' Not marked BC because I think support for using '' on the CLI was there by accident, and we don't seem to have documented it. Differential Revision: https://phab.mercurial-scm.org/D3018

tests: add test showing current parse of empty string symbol in revset We support e.g. parents(""), but I think that's by accident and I'll change it soon. Differential Revision: https://phab.mercurial-scm.org/D3017

clone: rename "rev" to "revs" since there can be many It was a little tricky in hg.clone(), since there was a local "revs" variable defined there, but "rev" was never used after "revs", so I just overwrote it. Note that clonewithshare() should also have its "rev" argument renamed to "revs", but I'll leave that to someone else. Differential Revision: https://phab.mercurial-scm.org/D3016

parseurl: consistently call second output "branches" Differential Revision: https://phab.mercurial-scm.org/D3015

templatefuncs: do not crash because of invalid value fed to mailmap()

scmutil: deprecate revpairnodes() Differential Revision: https://phab.mercurial-scm.org/D3012

tests: use context-return revpair() in autodiff Differential Revision: https://phab.mercurial-scm.org/D3013

fileset: use context-returning revpair() Differential Revision: https://phab.mercurial-scm.org/D3011

status: use context-returning revpair() Differential Revision: https://phab.mercurial-scm.org/D3010

diff: simplify by converting contexts to nodeids a little later Differential Revision: https://phab.mercurial-scm.org/D3009

diff: use context-returning revpair() Differential Revision: https://phab.mercurial-scm.org/D3008

extdiff: use context-returning revpair() Differential Revision: https://phab.mercurial-scm.org/D3007

scmutil: make revpair() return context objects (API) Differential Revision: https://phab.mercurial-scm.org/D3006

scmutil: introduce deprecated alias for revpair() revsingle() returns a context object, revpair() returns nodeids, revrange() returns integer revisions (in a revset). I'm going to reduce this inconsistency by making revpair() return context objects. Changing the return type is not nice to extensions, so this patch introduces a nodeid-returning version of revpair() that they can detect and use. Update callers to the new function so we can change revpair() itself and then migrate them back one by one. Differential Revision: https://phab.mercurial-scm.org/D3005

lfs: ensure the transfer request is for a known URI Since the dispatching code only checks the beginning of the string, this enforces that there's only one more path component.

lfs: avoid an improper usage of os.path.basename() to parse a URI

lfs: add an experimental knob to disable blob serving The use case here is the server admin may want to store the blobs elsewhere. As it stands now, the `lfs.url` config on the client side is all that enforces this (the web.allow-* permissions aren't able to block LFS blobs without also blocking normal hg traffic). The real solution to this is to implement the 'verify' action on the client and server, but that's not a near term goal. Whether this is useful in its own right, and should be promoted out of experimental at some point is TBD. Since the other two tests that deal with LFS and `hg serve` are already complex and have #testcases, this seems like a good time to start a new test dedicated to access checks against the server. Instead of conditionally wrapping the wire protocol handler, I put this in the handler because I'd still like to bring the annotations in from the evolve extension in order to set up the wrapping. The 400 status probably isn't great, but that's what it would be for existing `hg serve` instances without support for serving blobs.

stringutil: edit comment to reflect actual data type name In development the data type used to hold an email/name pair was called a "mailmaptup" since it was implemented as a namedtuple. The implementation has since been changed to use an @attr.s decorated class named mailmapping. This commit changes a comment to reflect this change. Differential Revision: https://phab.mercurial-scm.org/D3004

stringutil: improve check for failed mailmap line parsing The existing check for a bad mailmap file entry fails with inputs like b'>@<'. This commit adds a function to check if a sufficient amount of information has been parsed from a mailmap file entry. At minimum, one email must be found (assumed to be the commit email). If email is not empty and no names are found, then there must be two emails. If there are at least one email and name, the mapping is valid. Differential Revision: https://phab.mercurial-scm.org/D3003

stringutil: rename local email/names variables to their plural forms email and name variables are renamed to emails and names (respectively). This is because the email variable name shadows the email function within the stringutil module. Since we are renaming email, we also rename name for consistency. Differential Revision: https://phab.mercurial-scm.org/D3002

templatefuncs: remove redundant "or author" from mailmap return statement Differential Revision: https://phab.mercurial-scm.org/D3001

lfs: add the 'Content-Type' header called out in the file transfer spec https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads

lfs: improve the client message when the server signals an object error Two things here. First, the previous message included a snippet of JSON, which tends to be long (and in the case of lfs-test-server, has no error message). Instead, give a concise message where possible, and leave the JSON to a debug output. Second, the server can signal issues other than a missing individual file. This change shows a corrupt file, but I'm debating letting the corrupt file get downloaded, because 1) the error code doesn't really fit, and 2) having it locally makes forensics easier. Maybe need a config knob for that.

check-code: tighten the check for `ls -R` Otherwise, this was flagging `... lfs.serve=False -R server ...` in the tests.

infinitepush: add tests for `hg pull -r <rev>` This patch adds test for `hg pull -r <rev>` when the infinitepush extension is not present on the client side and the server by defaults pushes all the incoming push to bundlestore. As the tests show, if a the changeset was applied to the server, that can be pulled, but if a changeset is in the bundlestore we cannot pull that yet. We should support that. Differential Revision: https://phab.mercurial-scm.org/D2998

infinitepush: use bundleoperation.source instead of hacking on tr Previous patches added a soutce attribute to bundle2.bundleoperation class which stores the command which leads to current bundleoperation. Let's use that to decide whether a processing a `hg unbundle` or not instead of hacking on transaction. Differential Revision: https://phab.mercurial-scm.org/D2997

bundle2: make source a mandatory argument for bundle2.applybundle() (API) Currently all the callers in the core pass the source argument, making it mandatory will help us storing right source value in bundleoperation() class. Differential Revision: https://phab.mercurial-scm.org/D2996

bundleoperation: pass the source argument from all the users We now have a source attribute to the bundle2.bundleoperation class which stores the operation which leads to the current bundling/unbundling. Let's make sure we pass source argument from all the users of the command. Differential Revision: https://phab.mercurial-scm.org/D2995

bunlde2: add 'source' as an optional argument to processbundle() This will help us to pass the source variable to bundleoperation class. Differential Revision: https://phab.mercurial-scm.org/D2994

bundle2: add 'source' atrribute to bundleoperation class This will help us in easily finding out which command leads to the current operation without hacking on the transaction. Differential Revision: https://phab.mercurial-scm.org/D2993

infinitepush: don't force ipv6 while connecting to mysql server Facebook internally enforces this but looks like we can't force this for pur users. Differential Revision: https://phab.mercurial-scm.org/D2992

infinitepush: drop the default value of config options which are registered Differential Revision: https://phab.mercurial-scm.org/D2991

infinitepush: replace `remotenames.hoist` with `remotenames.hoistedpeer` The remotenames.hoist config option was renamed to remotenames.hoistedpeer while moving to core as an extension. Let's start using the config option provided by the in-core extension. Differential Revision: https://phab.mercurial-scm.org/D2990

templater: drop global exception catcher from runfilter() (API) Now all built-in template filters declare input data types or handle type errors by themselves. .. api:: Template filters should declare input data type and/or catch AttributeError, ValueError, TypeError, etc. as needed. See the doc of ``registrar.templatefilters`` for details.

templatefilters: raise ProgrammingError if unencodable type passed to json() This shouldn't happen for any template data types (though I know it does because of some templater bugs.) Let's clarify it is a bug.

templatefilters: handle TypeError by count() Prepares for removing the weird exception catcher from runfilter().

keyword: declare input type of date filters as date Dropped redundant dateutil.parsedate(), which is now handled by the templater.

templatefilters: declare input type as date where appropriate I'm not sure if the templateutil.date type can be a thing. Currently it's just a constant.

templater: attach hint to input-type error of runfilter() Tests will be added by the next patch.

templatefuncs: use evaldate() where seems appropriate This means date("today") is allowed. Also fixes evaldate() to forcibly use the custom error message if specified.

templater: factor out function that parses argument as date tuple

templatefilters: declare input type as bytes where appropriate Some test outputs changed since input is now coerced to a byte string. I think that's okay. Maybe {date} should have some readable representation?

templatefilters: allow declaration of input data type Currently filters take an unwrapped value, which should have no hybrid magic but actually it does because stringify() relies on it. The 'intype' allows us to pre-process the magic by .e.g. evalstring() keeping filter functions as simple as they are now. stringify() is ported as an example. More follow.

hgweb: use registrar to declare "websub" template filter Prepares for adding 'intype' attribute.

procutil: redirect ui.fout to stderr while stdio is protected The new behavior seems slightly nicer as we can at least read the output. And this is similar to what the sshserver is doing, so we can probably reuse protectstdio() instead of the weird hook.redirect(True) hack.

procutil: unroll uin/uout loop in protectstdio() I'll change uout to be redirected to stderr.

context: drop support for changeid of type long (API?) I don't see a reason to support type long. It's pretty much the same type as int. There was some discussion about it on the mailing list around the time of ff2f90503d64 (context: work around `long` not existing on Python 3, 2017-03-11), but I couldn't find a good reason to keep it. There was some mention of hgtk doing "repo[long(rev)]", but that was in 2012. Differential Revision: https://phab.mercurial-scm.org/D2989

lfs: drop a duplicate blob verification method

server: minor code cleanup Suggested by Yuya after 77f9e95fe3c4, this is mostly using named values for stdio descriptors. The lockfile is also opened in binary mode when reading back content from the child.

server: refactor 'daemon_postexec' instructions into a dictionary

cbor: import CBORDecoder and CBOREncoder And format the imports so it is cleaner. Differential Revision: https://phab.mercurial-scm.org/D2978

py3: fix fix doctests to be bytes-safe

server: add an error feedback mechanism for when the daemon fails to launch There's a recurring problem on Windows where `hg serve -d` will randomly fail to spawn a detached process. The reason for the failure is completely hidden, and it takes hours to get a single failure on my laptop. All this does is redirect stdout/stderr of the child to a file until the lock file is freed, and then the parent dumps it out if it fails to spawn. I chose to put the output into the lock file because that is always cleaned up. There's no way to report errors after that anyway. On Windows, killdaemons.py is roughly `kill -9`, so this ensures that junk won't pile up. This may end up being a case of EADDRINUSE. At least that's what I saw spit out a few times (among other odd errors and missing output on Windows). But I also managed to get the same thing on Fedora 26 by running test-hgwebdir.t with --loop -j10 for several hours. Running `netstat` immediately after killing that run printed a wall of sockets in the TIME_WAIT state, which were gone a couple seconds later. I couldn't match up ports that failed, because --loop doesn't print out the message about the port that was used. So maybe the fix is to rotate the use of HGPORT[12] in the tests. But, let's collect some more data first.

tests: conditionalize test-stream-bundle-v2 for Windows

templatefuncs: add mailmap template function This commit adds a template function to support the .mailmap file in Mercurial repositories. The .mailmap file comes from git, and can be used to map new emails and names for old commits. The general use case is that someone may change their name or author commits under different emails and aliases, which would make these commits appear as though they came from different persons. The file allows you to specify the correct name that should be used in place of the author field specified in the commit. The mailmap file has 4 possible formats used to map old "commit" names to new "proper" names: 1. <proper@email.com> <commit@email.com> 2. Proper Name <commit@email.com> 3. Proper Name <proper@email.com> <commit@email.com> 4. Proper Name <proper@email.com> Commit Name <commit@email.com> Essentially there is a commit email present in each mailmap entry, that maps to either an updated name, email, or both. The final possible format allows commits authored by a person who used both an old name and an old email to map to a new name and email. To parse the file, we split by spaces and build a name out of every element that does not start with "<". Once we find an element that does start with "<" we concatenate all the name elements that preceded and add that as a parsed name. We then add the email as the first parsed email. We repeat the process until the end of the line, or a comment is found. We will be left with all parsed names in a list, and all parsed emails in a list, with the 0 index being the proper values and the 1 index being the commit values (if they were specified in the entry). The commit values are added as the keys to a dict, and with the proper fields as the values. The mapname function takes the mapping object and the commit author field and attempts to look for a corresponding entry. To do so we try (commit name, commit email) first, and if no results are returned then (None, commit email) is also looked up. This is due to format 4 from above, where someone may have a mailmap entry with both name and email, and if they don't it is possible they have an entry that uses only the commit email. Differential Revision: https://phab.mercurial-scm.org/D2904

extdiff: document that it copies modified files back to working directory Differential Revision: https://phab.mercurial-scm.org/D2976

zope: force module import by importing symbols Previously, we tried to import a module and handle the ImportError. Our lazy module importer doesn't verify the module exists and returns a dummy object representing the module. Only once we attempt to load a symbol in the module does the ImportError get raises. This means that simple imports inside `try..except ImportError` don't detect missing modules. This commit changes imports in zope.interface to access symbols, thus forcing module load and triggering ImportError. This fixes zope.interface for pure builds. Differential Revision: https://phab.mercurial-scm.org/D2980

fix: remove unused imports Differential Revision: https://phab.mercurial-scm.org/D2977

infinitepush: introduce server option to route every push to bundlestore This patch introduces a new config option for server `infinitepush.pushtobundlestore` which if sets to True, the server will route each incoming push to the bundlestore and store all the parts i.e. changegroups, phases, obsmarkers in the bundlestore and won't be applied to the revlog. This config option does not need any client side wrapping and does not need any custom bundle2 part or stream level parameter to decide where the push should go. This is very useful for Mozilla CI use case where they have a central server that recieves pushes to trigger code-reviews, trigger a test run of CI, run static analysis etc. The server using the new config option can stash standalone bundles to the bundlestore and server can get access to individual revisions on demand. A new test file which has related tests are added for the config option. Differential Revision: https://phab.mercurial-scm.org/D2958

infinitepush: don't wrap bundle2.processparts while calling `hg unbundle` This patch adds dirty logic to check whether we are processing `hg unbundle` instead of an `hg incoming` to prevent the wrapping of bundle2.processparts function. Differential Revision: https://phab.mercurial-scm.org/D2957

inifnitepush: use utils.{stringutil|procutil}.* instead of util.* Recently in core, util.py is splitted into various modules in mercurial/utils/. Differential Revision: https://phab.mercurial-scm.org/D2956

infinitepush: delete the non-forward-move flag for hg push Differential Revision: https://phab.mercurial-scm.org/D2955

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

narrow: use repo.local() instead of isinstance() Differential Revision: https://phab.mercurial-scm.org/D2973

tests: add zope.interface to clang-format ignore list Differential Revision: https://phab.mercurial-scm.org/D2975

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

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

tests: ignore zope packages when running pyflakes Differential Revision: https://phab.mercurial-scm.org/D2972

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

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

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

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

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

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

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