Yuya Nishihara <yuya@tcha.org> [Tue, 03 Apr 2018 22:24:50 +0900] rev 37306
addremove: pass command-level similarity value down to scmutil.addremove()
Since we've changed to carry a similarity value by opts dict, it makes sense
to leave a string '0'-'100' value unmodified.
Augie Fackler <augie@google.com> [Tue, 03 Apr 2018 13:37:57 -0400] rev 37305
setup: add overlooked hgext.infinitepush package declaration
Will fix infinitepush tests that have been failing when run without --local.
Differential Revision: https://phab.mercurial-scm.org/D3038
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Apr 2018 09:12:15 -0700] rev 37304
tests: remove dependence on repo.changectx()
This was one of few remaining uses of repo.changectx() in core.
Differential Revision: https://phab.mercurial-scm.org/D3036
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Apr 2018 08:55:49 -0700] rev 37303
log: remove dependence on repo.changectx()
This was one of few remaining uses of repo.changectx() in core.
Differential Revision: https://phab.mercurial-scm.org/D3035
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Apr 2018 08:55:16 -0700] rev 37302
verify: remove dependence on repo.changectx()
This was one of few remaining uses of repo.changectx() in core.
Differential Revision: https://phab.mercurial-scm.org/D3034
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Apr 2018 08:46:58 -0700] rev 37301
bookmarks: switch from repo.changectx('.') to repo['.']
The two forms are synonymous and the new form is by far the more
common form.
Differential Revision: https://phab.mercurial-scm.org/D3033
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 14:52:57 -0700] rev 37300
stringutil: add function to pretty print an object
This is inspired by the pprint() module/function (which we can't
use because the output is different on Python 2 and 3 - namely the
use of b'' literals).
We hook it up to `hg debugwireproto` for printing the response to
a wire protocol command.
This foreshadows future peer work, which will support decoding
CBOR responses into rich data structures.
Differential Revision: https://phab.mercurial-scm.org/D2987
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 13:30:24 -0700] rev 37299
wireproto: add frame flag to denote payloads as CBOR
We may eventually want a separate frame type for this. But for
now this is the easiest to implement.
Differential Revision: https://phab.mercurial-scm.org/D2986
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 13:01:28 -0700] rev 37298
wireproto: implement custom __repr__ for frame
This version won't print the full payload (which could be large).
It also prints human friendly values for types and flags.
Differential Revision: https://phab.mercurial-scm.org/D2985
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 12:44:35 -0700] rev 37297
keepalive: implement readinto()
This is part of the standard I/O interface. It is used by the framing
protocol. So we need to implement it so frames can be decoded.
Differential Revision: https://phab.mercurial-scm.org/D2984
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 23 Mar 2018 16:24:53 -0700] rev 37296
wireproto: port protocol handler to zope.interface
zope.interface is superior to the abc module. Let's port to it.
As part of this, we add tests for interface conformance for
classes implementing the interface.
Differential Revision: https://phab.mercurial-scm.org/D2983
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 10:40:41 -0700] rev 37295
wireproto: separate commands tables for version 1 and 2 commands
We can't easily reuse existing command handlers for version 2
commands because the response types will be different. e.g. many
commands return nodes encoded as hex. Our new wire protocol is
binary safe, so we'll wish to encode nodes as binary.
We /could/ teach each command handler to look at the protocol
handler and change behavior based on the version in use. However,
this would make logic a bit unwieldy over time and would make
it harder to design a unified protocol handler interface. I think
it's better to create a clean break between version 1 and version 2
of commands on the server.
What I imagine happening is we will have separate @wireprotocommand
functions for each protocol generation. Those functions will parse the
request, dispatch to a common function to process it, then generate
the response in its own, transport-specific manner.
This commit establishes a separate table for tracking version 1
commands from version 2 commands. The HTTP server pieces have been
updated to use this new table.
Most commands are marked as both version 1 and version 2, so there is
little practical impact to this change.
A side-effect of this change is we now rely on transport registration
in wireprototypes.TRANSPORTS and certain properties of the protocol
interface. So a test had to be updated to conform.
Differential Revision: https://phab.mercurial-scm.org/D2982
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 10:12:02 -0700] rev 37294
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
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 14:05:29 -0700] rev 37293
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 14:34:32 -0700] rev 37292
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 10:50:36 -0700] rev 37291
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
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 15:05:39 -0700] rev 37290
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 13:59:56 -0700] rev 37289
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 11:00:16 -0700] rev 37288
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 13:57:22 -0700] rev 37287
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Mar 2018 13:51:22 -0700] rev 37286
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 02 Apr 2018 16:47:53 -0700] rev 37285
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 02 Apr 2018 16:28:20 -0700] rev 37284
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 02 Apr 2018 16:24:57 -0700] rev 37283
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
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 02 Apr 2018 15:55:50 -0700] rev 37282
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
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 21:03:16 +0900] rev 37281
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().
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Mar 2018 21:40:16 +0900] rev 37280
templater: extract private function to evaluate generator to byte string
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 23:14:21 +0900] rev 37279
templater: pass (context, mapping) down to unwrapvalue()
The same reason as why I made unwraphybrid() take a (context, mapping) pair.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:58:28 +0900] rev 37278
templater: drop unneeded generator from mappable object
Per the definition of the show() interface, it can return a bytes.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:56:42 +0900] rev 37277
templater: mark .gen as a private attribute
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 00:11:36 +0900] rev 37276
templatekw: do not directly call .gen
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:52:50 +0900] rev 37275
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)
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 20:09:05 +0900] rev 37274
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.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 16:18:33 -0700] rev 37273
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 23:52:43 -0700] rev 37272
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 31 Mar 2018 23:49:58 +0530] rev 37271
addremove: remove dry_run, similarity from scmutil.addremove (API)
Differential Revision: https://phab.mercurial-scm.org/D3000
Sangeet Kumar Mishra <mail2sangeetmishra@gmail.com> [Tue, 03 Apr 2018 12:16:19 +0530] rev 37270
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 09:18:01 -0700] rev 37269
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 08:43:08 -0700] rev 37268
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
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Apr 2018 00:12:29 +0530] rev 37267
children: use repo['.'] instead of repo['']
Differential Revision: https://phab.mercurial-scm.org/D3020
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 09:16:52 -0700] rev 37266
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 09:06:24 -0700] rev 37265
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 02 Apr 2018 08:46:07 -0700] rev 37264
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 01 Apr 2018 15:41:16 -0700] rev 37263
parseurl: consistently call second output "branches"
Differential Revision: https://phab.mercurial-scm.org/D3015
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Apr 2018 11:06:29 +0900] rev 37262
templatefuncs: do not crash because of invalid value fed to mailmap()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:34:15 -0700] rev 37261
scmutil: deprecate revpairnodes()
Differential Revision: https://phab.mercurial-scm.org/D3012
Martin von Zweigbergk <martinvonz@google.com> [Sun, 01 Apr 2018 09:30:44 -0700] rev 37260
tests: use context-return revpair() in autodiff
Differential Revision: https://phab.mercurial-scm.org/D3013
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:26:07 -0700] rev 37259
fileset: use context-returning revpair()
Differential Revision: https://phab.mercurial-scm.org/D3011
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:31:28 -0700] rev 37258
status: use context-returning revpair()
Differential Revision: https://phab.mercurial-scm.org/D3010
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:49:44 -0700] rev 37257
diff: simplify by converting contexts to nodeids a little later
Differential Revision: https://phab.mercurial-scm.org/D3009
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:25:02 -0700] rev 37256
diff: use context-returning revpair()
Differential Revision: https://phab.mercurial-scm.org/D3008
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:38:53 -0700] rev 37255
extdiff: use context-returning revpair()
Differential Revision: https://phab.mercurial-scm.org/D3007
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:10:46 -0700] rev 37254
scmutil: make revpair() return context objects (API)
Differential Revision: https://phab.mercurial-scm.org/D3006
Martin von Zweigbergk <martinvonz@google.com> [Sat, 31 Mar 2018 23:37:25 -0700] rev 37253
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
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 23:58:08 -0400] rev 37252
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.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 23:47:56 -0400] rev 37251
lfs: avoid an improper usage of os.path.basename() to parse a URI
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 15:20:43 -0400] rev 37250
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.
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 13:01:20 -0400] rev 37249
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
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 11:36:55 -0400] rev 37248
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
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 10:21:39 -0400] rev 37247
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
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 10:13:42 -0400] rev 37246
templatefuncs: remove redundant "or author" from mailmap return statement
Differential Revision: https://phab.mercurial-scm.org/D3001
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Feb 2018 19:56:59 -0500] rev 37245
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
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Feb 2018 23:44:02 -0500] rev 37244
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.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 15:54:26 -0400] rev 37243
check-code: tighten the check for `ls -R`
Otherwise, this was flagging `... lfs.serve=False -R server ...` in the tests.
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 16:41:17 +0530] rev 37242
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:56:57 +0530] rev 37241
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:54:12 +0530] rev 37240
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:51:34 +0530] rev 37239
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:49:16 +0530] rev 37238
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:47:43 +0530] rev 37237
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 10:13:05 -0700] rev 37236
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
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:33:37 +0530] rev 37235
infinitepush: drop the default value of config options which are registered
Differential Revision: https://phab.mercurial-scm.org/D2991
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 31 Mar 2018 14:31:29 +0530] rev 37234
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
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:57:07 +0900] rev 37233
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.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:53:08 +0900] rev 37232
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.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:47:44 +0900] rev 37231
templatefilters: handle TypeError by count()
Prepares for removing the weird exception catcher from runfilter().
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 17:02:39 +0900] rev 37230
keyword: declare input type of date filters as date
Dropped redundant dateutil.parsedate(), which is now handled by the
templater.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 16:12:44 +0900] rev 37229
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.
Yuya Nishihara <yuya@tcha.org> [Tue, 20 Mar 2018 22:57:36 +0900] rev 37228
templater: attach hint to input-type error of runfilter()
Tests will be added by the next patch.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:58:22 +0900] rev 37227
templatefuncs: use evaldate() where seems appropriate
This means date("today") is allowed.
Also fixes evaldate() to forcibly use the custom error message if specified.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:55:31 +0900] rev 37226
templater: factor out function that parses argument as date tuple
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:42:28 +0900] rev 37225
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?
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 15:14:58 +0900] rev 37224
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.
Yuya Nishihara <yuya@tcha.org> [Mon, 19 Mar 2018 20:39:06 +0900] rev 37223
hgweb: use registrar to declare "websub" template filter
Prepares for adding 'intype' attribute.
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Mar 2018 12:15:33 +0900] rev 37222
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.
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Mar 2018 12:07:18 +0900] rev 37221
procutil: unroll uin/uout loop in protectstdio()
I'll change uout to be redirected to stderr.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Mar 2018 22:46:22 -0700] rev 37220
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
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Mar 2018 00:02:31 -0400] rev 37219
lfs: drop a duplicate blob verification method
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Mar 2018 23:32:06 -0400] rev 37218
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.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Mar 2018 23:21:46 -0400] rev 37217
server: refactor 'daemon_postexec' instructions into a dictionary
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Mar 2018 13:37:19 -0700] rev 37216
cbor: import CBORDecoder and CBOREncoder
And format the imports so it is cleaner.
Differential Revision: https://phab.mercurial-scm.org/D2978
Yuya Nishihara <yuya@tcha.org> [Sat, 31 Mar 2018 10:28:18 +0900] rev 37215
py3: fix fix doctests to be bytes-safe
Matt Harbison <matt_harbison@yahoo.com> [Wed, 28 Mar 2018 00:11:09 -0400] rev 37214
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.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Mar 2018 20:53:36 -0400] rev 37213
tests: conditionalize test-stream-bundle-v2 for Windows
Connor Sheehan <sheehan@mozilla.com> [Mon, 19 Mar 2018 11:16:21 -0400] rev 37212
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
Kyle Lippincott <spectral@google.com> [Fri, 30 Mar 2018 12:16:46 -0700] rev 37211
extdiff: document that it copies modified files back to working directory
Differential Revision: https://phab.mercurial-scm.org/D2976
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 30 Mar 2018 13:39:06 -0700] rev 37210
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
Danny Hooper <hooper@google.com> [Fri, 30 Mar 2018 13:17:20 -0700] rev 37209
fix: remove unused imports
Differential Revision: https://phab.mercurial-scm.org/D2977
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 27 Mar 2018 17:26:43 +0530] rev 37208
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
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 27 Mar 2018 17:19:02 +0530] rev 37207
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
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 27 Mar 2018 14:15:42 +0530] rev 37206
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
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 30 Mar 2018 12:50:06 -0700] rev 37205
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 37204
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 37203
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 37202
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 37201
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 37200
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 37199
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 37198
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 37197
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 37196
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 37195
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