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.
cext: move _dict_new_presized() to header
Prepares for splitting encoding functions from parsers.c.
ui: restore behavior to ignore some I/O errors (
issue5658)
e9646ff34d55 and
1bfb9a63b98e refactored ui methods to no longer
silently swallow some IOError instances. This is arguably the
correct thing to do. However, it had the unfortunate side-effect
of causing StdioError to bubble up to sensitive code like
transaction aborts, leading to an uncaught exceptions and failures
to e.g. roll back a transaction. This could occur when a remote
HTTP or SSH client connection dropped. The new behavior is
resulting in semi-frequent "abandonded transaction" errors on
multiple high-volume repositories at Mozilla.
This commit effectively reverts
e9646ff34d55 and
1bfb9a63b98e to
restore the old behavior.
I agree with the principle that I/O errors shouldn't be ignored.
That makes this change... unfortunate. However, our hands are tied
for what to do on stable. I think the proper solution is for the
ui's behavior to be configurable (possibly via a context manager).
During critical sections like transaction rollback and abort, it
should be possible to suppress errors. But this feature would not
be appropriate on stable.