@peer.batchable decorated generator functions have two forms:
yield value, None
and
yield args, future
yield value
These forms have been present since the decorator was introduced.
There are currently no in-repo consumers of the first form. So this
commit removes support for it.
Note that remoteiterbatcher.submit() asserts the 2nd form. And
3bcb9f9a4a63 removed the last user of remotebatcher, forcing everyone
to remoteiterbatcher. So anything relying on this in the wild would
have been broken since 3bcb9f9a4a63.
.. api::
@peer.batchable can no longer emit local values
Differential Revision: https://phab.mercurial-scm.org/D318
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
This method was added in 6fb54510b150. 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.
3bcb9f9a4a63 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
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.
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.
This vulnerability was fixed by the previous patch and there were more ways
to exploit than using '|shellcmd'. So it doesn't make sense to reject only
pipe character.
Test cases are updated to actually try to exploit the bug. As the SSH bridge
of git/svn subrepos are not managed by our code, the tests for non-hg subrepos
are just removed.
This may be folded into the original patches.
This vulnerability was fixed by the previous patch and there were more ways
to exploit than using '|shellcmd'. So it doesn't make sense to reject only
pipe character.
Test cases are updated to actually try to exploit the bug. As the SSH bridge
of git/svn subrepos are not managed by our code, the tests for non-hg subrepos
are just removed.
This may be folded into the original patches.
Without this flag, compilation fails with:
hgclient.c: In function 'hgc_open':
hgclient.c:466: error: 'O_DIRECTORY' undeclared (first use in this function)
hgclient.c:466: error: (Each undeclared identifier is reported only once
hgclient.c:466: error: for each function it appears in.)
Differential Revision: https://phab.mercurial-scm.org/D260
CentOS 5 has reached end-of-life. A working build for it is still
possible using 'vault.centos.org'.
Differential Revision: https://phab.mercurial-scm.org/D261
Without this patch on Windows 'hg ci -i' hangs waiting for user input
and "examine changes to 'file'? [Ynesfdaq?]" is never displayed (at least
if the diff is sufficiently small). When Ctrl+C is pressed, this prompt
becomes visible, which suggests that the buffer just wasn't flushed.
I've never seen this happening on Linux, but this looks harmless enough
to not platform-gate it.
As we changed the meaning of unstable between the old vocabulary and the new
one, we can't reuse the unstable method name at the risk of breaking
extensions calling unstable and getting a wrong result.
Instead rename troubled into isunstable so extensions will continue to work.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D242
Rename troubles context method into instabilities.
Copy the old troubles method and add a deprecation warning. This way
extensions calling troubles will see the deprecation warning but will not
break due to new return values.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D238
This moves manifest stripping to a separate function so implementations of the
manifest that don't support stripping can replace this function with a no-op.
I considered adding a strip api to the manifestlog, so other implementations
could make it a no-op there, but it seems like strip might be unique to the
revlog implementation, and therefore shouldn't be present on the generic api.
Differential Revision: https://phab.mercurial-scm.org/D292
This refactors broken linkrev collection such that manifest collection is in a
separate function. This allows extensions to replace the manifest collection
with a non-revlog oriented version.
I considered moving the collect changes function onto the manifestlog itself, so
it would be behind the abstraction, but since the store we're building doesn't
even have the concept of strip, embeding that concept in the manifestlog api
seemed odd.
Differential Revision: https://phab.mercurial-scm.org/D291
