wireproto: properly implement batchable checking
remoteiterbatcher (unlike remotebatcher) only supports batchable
commands. This claim can be validated by comparing their
implementations of submit() and noting how remoteiterbatcher assumes
the invoked method has a "batchable" attribute, which is set by
@peer.batchable.
remoteiterbatcher has a custom __getitem__ that was trying to
validate that only batchable methods are called. However, it was only
validating that the called method exists, not that it is batchable.
This wasn't a big deal since remoteiterbatcher.submit() would raise
an AttributeError attempting to `mtd.batchable(...)`.
Let's fix the check and convert it to ProgrammingError, which may
not have been around when this was originally implemented.
Differential Revision: https://phab.mercurial-scm.org/D317
largefiles: remove remotestore.batch()
This method was added in
9e1616307c4c. AFAICT it didn't do anything at
inception. If it did, there was no test coverage for it because
changing it to raise doesn't fail any tests at that revision.
b6e71f8af5b8 later refactored all remote.batch() calls to
remote.iterbatch(). So if this was somehow used, it isn't called
any more because there are no calls to .batch() remaining in the
repo.
I suspect the original patch author got confused by the distinction
between the peer/remote interface and the largefiles store. The lf
store is a gateway to a peer instance. It exposes additional
lf-specific methods to execute against a peer. However, it is not
a peer and doesn't need to implement batch() because peer itself
does that.
Differential Revision: https://phab.mercurial-scm.org/D316
histedit: check first changeset for verb "roll" or "fold" (
issue5498)
If someone changes "pick" to "roll" or "fold" for the first
changeset in a histedit rule Mercurial could remove a wrong
changeset if the phase is non-public.
roll or fold for the first changeset should be invalid.
encoding: drop circular import by proxying through '<policy>.charencode'
I decided not to split charencode.c to new C extension module because it
would duplicate binary codes unnecessarily.
policy: reroute proxy modules internally
This allows us to split encoding functions from pure.parsers without doing
that for cext.parsers. See the next patch for why.
cext: factor out header for charencode.c
This merges a part of util.h with the header which should exist for
charencode.c.
cext: split character encoding functions to new compilation unit
This extracts charencode.c from parsers.c, which seems big enough for me
to hesitate to add new JSON functions. Still charencode.o is linked to
parsers.so to avoid duplication of binary codes.