lfs: autoload the extension when cloning from repo with lfs enabled This is based on a patch by Gregory Szorc. I made small adjustments to clean up the messaging when the server has the extension enabled, but the client has it disabled (to prevent autoloading). Additionally, I added a second server capability to distinguish between the server having the extension enabled, and the server having LFS commits. This helps prevent unnecessary requirement propagation- the client shouldn't add a requirement that the server doesn't have, just because the server had the extension loaded. The TODO I had about advertising a capability when the server can natively serve up blobs isn't relevant anymore (we've had 2 releases that support this), so I dropped it. Currently, we lazily add the "lfs" requirement to a repo when we first encounter LFS data. Due to a pretxnchangegroup hook that looks for LFS data, this can happen at the end of clone. Now that we have more control over how repositories are created, we can do better. This commit adds a repo creation option to add the "lfs" requirement. hg.clone() sets this creation option if the remote peer is advertising lfs usage (as opposed to just support needed to push). So, what this change effectively does is have cloned repos automatically inherit the "lfs" requirement. Differential Revision: https://phab.mercurial-scm.org/D5130

testing: switch to inserting deltas As the comment in the test specifies, this was relying on storage backend implementation details. We switch to inserting a raw delta, skipping the regular insert path to ensure we have the desired outcome. This required implementing support for handling deltas in the revlog testing code. Differential Revision: https://phab.mercurial-scm.org/D5116

testing: remove expectation of error on bad node insert addgroup() doesn't necessarily validate the hashes of each incoming revision. This is an optimization that allows delta group application to complete faster. The fact that revlog raises in this particular test is an implementation detail due to the way revlogs are testing multiple deltas. Differential Revision: https://phab.mercurial-scm.org/D5115

storageutil: convert fileid to bytes to avoid cast to %s test-storage.py manages to trigger this on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5117

tests: use byte literals in test-storage.py This fixes a Python 3 breakage due to unknown key due to str/bytes type mismatch. # skip-blame just b'' literals Differential Revision: https://phab.mercurial-scm.org/D5114

py3: byte-stringify literals in test-keyword.t # skip-blame just some b'' prefixes

py3: flush std streams before/after running user code in heredoctest.py Otherwise, things written to stdout.buffer would be interleaved.

py3: rewrite StringIO fallback for Python 3

py3: reinvent print() function for contrib/hgclient.py

py3: work around unicode stdio streams in contrib/hgclient.py

py3: convert string literals to bytes in contrib/hgclient.py # skip-blame just many b'' prefixes

merge with stable

branchmap: remove redundant sort There is absoluty no benefit in sorting a list that's being merged into a set on the next line. The changelog.ancestors() call later on also doesn't benefit from a sorted sequence of revs. Differential Revision: https://phab.mercurial-scm.org/D5111

revset: drop special case of 'revset(...)' function in analyze We now have a valid no-op function. We no longer need the special case.

revset: document the `revset(...)` syntax We introduce a new "no-op" function to bear the documentation. In practice, the parsing step is skipping it so it is not even called. This will get fixed in the next changeset.

check-commit: update test expectation per removal of "double empty line" rule Follow up for 47084b5ffd80.

style: drop requirement to only use single lines between top-level objects Differential Revision: https://phab.mercurial-scm.org/D5105

py3: byteify extension in test-relink.t

f: fix a Python 3 bytes/string issue I suspect we should test this tool in isolation, but we don't yet. Oh well. Differential Revision: https://phab.mercurial-scm.org/D5061

tests: use regex instead of Python versions for archive hash changes It turns out this behavior changed between versions of Python 3. Let's just always accept either size or sha1, and move on. Differential Revision: https://phab.mercurial-scm.org/D5104

notify: a ton of encoding dancing to deal with the email module Almost fixes test-keyword.t on Python 3, but leaves us with some extremely confusing failures at the end of the test that seem related to the command server? Differential Revision: https://phab.mercurial-scm.org/D5100

tests: add missing b prefix in test-context-metadata.t # skip-blame just a b prefix Differential Revision: https://phab.mercurial-scm.org/D5109

context: raise runtime errors with sysstrs We should probably *not* use RuntimeError for this, but let's deal with that later, rather than as part of the Python 3 effort. Differential Revision: https://phab.mercurial-scm.org/D5108

rust: rustfmt config for hg-direct-ffi For now, we're duplicating it, but it would be probably a good idea to use a single one for the whole workspace (would have implications on the other crates as well)

rust: rustlazyancestors.__contains__ This changeset provides a Rust implementation of the iteration performed by lazyancestor.__contains__ It has the advantage over the Python iteration to use the 'seen' set encapsuled into the dedicated iterator (self._containsiter), rather than storing emitted items in another set (self._containsseen), and hence should reduce the memory footprint. Also, there's no need to convert intermediate emitted revisions back into Python integers. At this point, it would be tempting to implement the whole lazyancestor object in Rust, but that would lead to more C wrapping code (two objects) for little expected benefits.

help: fix a missing quote character in ui.tweakdefaults

rust: hooking into Python code We introduce a new class called 'rustlazyancestors' in the ancestors module, which is used only if parsers.rustlazyancestors does exist. The implementation of __contains__ stays unchanged, but is now backed by the Rust iterator. It would probably be a good candidate for further development, though, as it is mostly looping, and duplicates the 'seen' set. The Rust code could be further optimized, however it already gives rise to performance improvements: median timing from hg perfancestors: - on pypy: before: 0.077566s after: 0.016676s -79% - on mozilla central: before: 0.190037s after: 0.082225s -58% - on a private repository (about one million revisions): before: 0.567085s after: 0.108816s -80% - on another private repository (about 400 000 revisions): before: 1.440918s after: 0.290116s -80% median timing for hg perfbranchmap base - on pypy: before: 1.383413s after: 0.507993s -63% - on mozilla central: before: 2.821940s after: 1.258902s -55% - on a private repository (about one million revisions): before: 77.065076s after: 16.158475s -80% - on another private repository (about 401 000 revisions): before: 7.835503s after: 3.545331s -54%

py3: fix test-propertycache.py Differential Revision: https://phab.mercurial-scm.org/D5101

py3: fix test-dirstate-race.t Differential Revision: https://phab.mercurial-scm.org/D5106

help: adding a proper declaration for shortlist/basic commands (API) We previously used the '^' prefix to indicate that a command should be shown on the short list (shown for just "hg"), but that's a horrible hack, so I'm removing it. Differential Revision: https://phab.mercurial-scm.org/D5069