tests: fix "running x tests using y ... " output in a few more places These seem to have been missed by 1039404c5e1d (run-tests: print number of tests and parallel process count, 2018-10-13). Differential Revision: https://phab.mercurial-scm.org/D5145

py3: fix test-hardlinks.t Differential Revision: https://phab.mercurial-scm.org/D5096

exchange: support declaring pull depth Upcoming commits will teach exchangev2 how to perform a shallow clone. This commit teaches hg.clone(), exchange.pull(), and exchange.pulloperation to recognize a request for a shallow clone by having the caller specify a numeric depth of the maximum number of ancestor changesets to fetch. There are certainly other ways we could control shallow-ness. But this one is simple to implement and is also how the narrow extension controls things. So it seems to make sense to start here. Differential Revision: https://phab.mercurial-scm.org/D5136

exchangev2: support for calling rawstorefiledata to retrieve raw files This is somewhat hacky. For that I apologize. At the 4.8 Sprint, we decided we wanted to land support in wireprotov2 for doing a partial clone with changelog and manifestlog bootstrapped from a "stream clone" like primitive. This commit implements the client-side bits necessary to facilitate that. If the new server-side command for obtaining raw files data is available, we call it to get the raw files for the changelog and manifestlog. Then we fall through to an incremental pull. But when fetching files data, instead of using the list of a changesets and manifests that we fetched via the "changesetdata" command, we do a linear scan of the repo and resolve the changeset and manifest nodes along with the manifest linkrevs. Differential Revision: https://phab.mercurial-scm.org/D5135

wireprotov2: implement command for retrieving raw store files Implementing shallow clone of the changelog is hard. We want the 4.8 release to have a fast implementation of partial clone in wireprotov2. In order to achieve fast, we can't use deltas for transferring changelog and manifestlog data. Per discussions at the 4.8 sprint, this commit implements a somwwhat hacky and likely-to-be-changed-drastically-or-dropped command in wireprotov2 that facilitates access to raw store files, namely the changelog and manifestlog. Using this command, clients can perform a "stream clone" of sorts for just the changelog and manifestlog. This will allow clients to fetch the changelog and manifest revlogs, stream them to disk (which should be fast), then follow up filesdata requests for files revision data for a particular changeset. Differential Revision: https://phab.mercurial-scm.org/D5134

wireprotov2: add response type that serializes to indefinite length bytestring This will be needed in a future patch. Differential Revision: https://phab.mercurial-scm.org/D5133

exchangev2: recognize narrow patterns when pulling pulloperation instances were recently taught to record file include and exclude patterns to facilitate narrow file transfer. Teaching the exchangev2 code to transfer a subset of files is as simple as constructing a narrow matcher from these patterns and filtering all seen file paths through it. Keep in mind that this change only influences file data: we're still fetching all changeset and manifest data. So, there's still a ton of "partial clone" to implement in exchangev2. On a personal note, I derive gratification that this feature requires very few lines of new code to implement. To test this, we implemented a minimal extension which allows us to specify --include/--exclude to clone. While the narrow extension provides these arguments, I explicitly wanted to test this functionality without the narrow extension enabled, as that extension monkeypatches various things and I want to isolate the behavior of core Mercurial. Differential Revision: https://phab.mercurial-scm.org/D5132

sqlitestore: file storage backend using SQLite This commit provides an extension which uses SQLite to store file data (as opposed to revlogs). As the inline documentation describes, there are still several aspects to the extension that are incomplete. But it's a start. The extension does support basic clone, checkout, and commit workflows, which makes it suitable for simple use cases. One notable missing feature is support for "bundlerepos." This is probably responsible for the most test failures when the extension is activated as part of the test suite. All revision data is stored in SQLite. Data is stored as zstd compressed chunks (default if zstd is available), zlib compressed chunks (default if zstd is not available), or raw chunks (if configured or if a compressed delta is not smaller than the raw delta). This makes things very similar to revlogs. Unlike revlogs, the extension doesn't yet enforce a limit on delta chain length. This is an obvious limitation and should be addressed. This is somewhat mitigated by the use of zstd, which is much faster than zlib to decompress. There is a dedicated table for storing deltas. Deltas are stored by the SHA-1 hash of their uncompressed content. The "fileindex" table has columns that reference the delta for each revision and the base delta that delta should be applied against. A recursive SQL query is used to resolve the delta chain along with the delta data. By storing deltas by hash, we are able to de-duplicate delta storage! With revlogs, the same deltas in different revlogs would result in duplicate storage of that delta. In this scheme, inserting the duplicate delta is a no-op and delta chains simply reference the existing delta. When initially implementing this extension, I did not have content-indexed deltas and deltas could be duplicated across files (just like revlogs). When I implemented content-indexed deltas, the size of the SQLite database for a full clone of mozilla-unified dropped: before: 2,554,261,504 bytes after: 2,488,754,176 bytes Surprisingly, this is still larger than the bytes size of revlog files: revlog files: 2,104,861,230 bytes du -b: 2,254,381,614 I would have expected storage to be smaller since we're not limiting delta chain length and since we're using zstd instead of zlib. I suspect the SQLite indexes and per-column overhead account for the bulk of the differences. (Keep in mind that revlog uses a 64-byte packed struct for revision index data and deltas are stored without padding. Aside from the 12 unused bytes in the 32 byte node field, revlogs are pretty efficient.) Another source of overhead is file name storage. With revlogs, file names are stored in the filesystem. But with SQLite, we need to store file names in the database. This is roughly equivalent to the size of the fncache file, which for the mozilla-unified repository is ~34MB. Since the SQLite database isn't append-only and since delta chains can reference any delta, this opens some interesting possibilities. For example, we could store deltas in reverse, such that fulltexts are stored for newer revisions and deltas are applied to reconstruct older revisions. This is likely a more optimal storage strategy for version control, as new data tends to be more frequently accessed than old data. We would obviously need wire protocol support for transferring revision data from newest to oldest. And we would probably need some kind of mechanism for "re-encoding" stores. But it should be doable. This extension is very much experimental quality. There are a handful of features that don't work. It probably isn't suitable for day-to-day use. But it could be used in limited cases (e.g. read-only checkouts like in CI). And it is also a good proving ground for alternate storage backends. As we continue to define interfaces for all things storage, it will be useful to have a viable alternate storage backend to see how things shake out in practice. test-storage.py passes on Python 2 and introduces no new test failures on Python 3. Having the storage-level unit tests has proved to be insanely useful when developing this extension. Those tests caught numerous bugs during development and I'm convinced this style of testing is the way forward for ensuring alternate storage backends work as intended. Of course, test coverage isn't close to what it needs to be. But it is a start. And what coverage we have gives me confidence that basic store functionality is implemented properly. Differential Revision: https://phab.mercurial-scm.org/D4928

storageutil: extract most of peek_censored from revlog This function is super hacky and isn't correct 100% of the time. I'm going to need this functionality on a future non-revlog store. Let's copy things to storageutil so this code only exists once. Differential Revision: https://phab.mercurial-scm.org/D5118

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

help: assigning topic categories Differential Revision: https://phab.mercurial-scm.org/D5068

help: assigning categories to existing commands I'm separating this into its own commit so people can bikeshed over the actual categorization (vs the support for categories). These categories are based on the help implementation we've been using internally at Google, and have had zero complaints. Differential Revision: https://phab.mercurial-scm.org/D5067

help: splitting the topics by category Differential Revision: https://phab.mercurial-scm.org/D5066

help: adding support for command categories Differential Revision: https://phab.mercurial-scm.org/D5065

notify: just use email.errors email.Errors is a proxy object to email.errors on Python 2.

rust-chg: add struct holding information needed to spawn server process The Locator will handle the initialization of the connection. It will spawn server processes as needed.

rust-chg: install logger if $CHGDEBUG is set This is modeled after the example logger and debugmsg() of chg/util.c. https://docs.rs/log/0.4.5/log/#implementing-a-logger

rust-chg: depend on log and tokio_timer I'll start porting the daemon management functions from chg of C, which will be difficult to debug without some logging facility. AFAIK, the log crate is easy-to-use and widely used. tokio_timer provides sleep() helper to be used while spawning a server process.

rust-chg: suppress panic while writing chg error to stderr Otherwise "chg >/dev/full 2>&1" would exit with 101. Spotted by test-basic.t.

logcmdutil: add a helpful assertion to catch mistyped templates early This would have made a defect in test-notify.t much easier to figure out. Differential Revision: https://phab.mercurial-scm.org/D5097

notify: adapt to new location of email module's errors Differential Revision: https://phab.mercurial-scm.org/D5099

notify: add some b prefixes # skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D5098

py3: fix test-diff-color.t Differential Revision: https://phab.mercurial-scm.org/D5095

py3: fix test-revlog.t The mpatchError has a trailing comma on Python 2 but not on Python 3, so use a glob to handle both Python 2 and Python 3. Differential Revision: https://phab.mercurial-scm.org/D5093

fuzz: try *even harder* to prevent Python from looking up usernames Differential Revision: https://phab.mercurial-scm.org/D5092

wireproto: fix incorrect function name in docstring The docstring for `iwireprotocolcommandcacher` references an `onoutputfinished` method. The actual name of the function is `onfinished`. Differential Revision: https://phab.mercurial-scm.org/D5090

py3: fix test-status.t Differential Revision: https://phab.mercurial-scm.org/D5089

formatter: make debug output prettier "(glob)" won't be needed since pprintgen() can print dict items in stable order.

stringutil: allow to specify initial indent level of pprint() I want to pprint() an inner object, which starts with level=1 indent.

stringutil: make level parameter of pprintgen() 0-origin I think this makes more sense in that the level is incremented where nesting goes one more deep.

formatter: use stringutil.pprint() in debug output to drop b''

rust: exposing in parsers module To build with the Rust code, set the HGWITHRUSTEXT environment variable. At this point, it's possible to instantiate and use a rustlazyancestors object from a Python interpreter. The changes in setup.py are obviously a quick hack, just good enough to test/bench without much refactoring. We'd be happy to improve on that with help from the community. Rust bindings crate gets compiled as a static library, which in turn gets linked within 'parsers.so' With respect to the plans at https://www.mercurial-scm.org/wiki/OxidationPlan this would probably qualify as "roll our own FFI". Also, it doesn't quite meet the target of getting rid of C code, since it brings actually more, yet: - the new C code does nothing else than parsing arguments and calling Rust functions. In particular, there's no complex allocation involved. - subsequent changes could rewrite more of revlog.c, this time resulting in an overall decrease of C code and unsafety.

rust: iterator bindings to C code In this changeset, still made of Rust code only, we expose the Rust iterator for instantiation and consumption from C code. The idea is that both the index and index_get_parents() will be passed from the C extension, hence avoiding a hard link dependency to parsers.so, so that the crate can still be built and tested independently. On the other hand, parsers.so will use the symbols defined in this changeset.

rust: pure Rust lazyancestors iterator This is the first of a patch series aiming to provide an alternative implementation in the Rust programming language of the _lazyancestorsiter from the ancestor module. This iterator has been brought to our attention by the people at Octobus, as a potential good candidate for incremental "oxydation" (rewriting in Rust), because it has shown performance issues lately and it merely deals with ints (revision numbers) obtained by calling the index, whih should be directly callable from Rust code, being itself implemented as a C extension. The idea behind this series is to provide a minimal example of Rust code collaborating with existing C and Python code. To open the way to gradually rewriting more of Mercurial's Python code in Rust, without being forced to pay a large initial cost of rewriting the existing fast core into Rust. This patch does not introduce any bindings to other Mercurial code yet. Instead, it introduces the necessary abstractions to address the problem independently, and unit-test it. Since this is the first use of Rust as a Python module within Mercurial, the hg-core crate gets created within this patch. See its Cargo.toml for more details. Someone with a rustc/cargo installation may chdir into rust/hg-core and run the tests by issuing: cargo test --lib The algorithm is a bit simplified (see details in docstrings), and at its simplest becomes rather trivial, showcasing that Rust has batteries included too: BinaryHeap, the Rust analog of Python's heapq does actually all the work. The implementation can be further optimized and probably be made more idiomatic Rust.

run-tests: restore quoting the python executable for running *.py tests This was accidentally dropped in 8cf459d8b111.

tests: replace `cd ..` with an absolute path in a couple ssh tests These tests are broken under py3 on Windows to the point where the `cd ..` was actually escaping into the system wide $TEMP. The subsequent `hg init` created a repo there, and then added a local extension to the hgrc. This breaks every single subsequent test when it tries to `hg init` in its $TESTTMP, and can't load the localwrite.py extension. And since I botched this the first time and replaced the wrong `cd ..`, this just replaces all of them. I've noticed test garbage in $TEMP recently, and maybe this will help. Perhaps `hg init` shouldn't load the config for the local repo, but this is an easy enough workaround for now.

lfs: register the flag processors per repository Previously, enabling the extension for any repo in commandserver or hgweb would enable the flags on all repos. Since localrepo.resolverevlogstorevfsoptions() is called so early, the check to see if the extension is enabled on the repo (which hasn't been instantiated yet) is a bit awkward. But I don't see a better way.

revlog: allow flag processors to be applied via store options This allows flag processors to be registered to specific repos in an extension by wrapping localrepo.resolverevlogstorevfsoptions(). I wanted to add the processors via a function on localrepo, but some of the places where the processors are globally registered don't have a repository available. This makes targeting specific repos in the wrapper awkward, but still manageable.

py3: use str to query registry values on Windows This blew up launching any command if extdiff processed a tool with a regkey config.

py3: convert "usage" literal to bytes Here _() is practically an identity function, but we shouldn't pass in unicode to _().

churn: remove redundant round() To my surprise, the int() is required. Spotted by Mads when he reviewed D5063. Thanks! Differential Revision: https://phab.mercurial-scm.org/D5086

py3: use py3 as the test tag, dropping the k Differential Revision: https://phab.mercurial-scm.org/D5079

tests: fix inline extension in test-fncache.t for Python 3 # skip-blame just some b prefixing Differential Revision: https://phab.mercurial-scm.org/D5083

py3: 3 more passing tests Differential Revision: https://phab.mercurial-scm.org/D5082

simplemerge: port to Python 3 Differential Revision: https://phab.mercurial-scm.org/D5081

contrib: fix up output in check-config.py to use strs to avoid b prefixes Differential Revision: https://phab.mercurial-scm.org/D5059

context: open files in bytes mode I'm stunned this open() call has survived this long without the b in the mode - it seems like it should have been a source of bugs somewhere... Differential Revision: https://phab.mercurial-scm.org/D5080

tests: fix up test-hghave for recent run-tests change to use more CPUs Differential Revision: https://phab.mercurial-scm.org/D5085

py3: fix test-parse-date.t Differential Revision: https://phab.mercurial-scm.org/D5084

obsolete: don't translate internal error message AFAIK, it's caught only by "hg debugobsolete", so it's pretty much a programming error.

py3: get around unicode docstrings in test-encoding-textwrap.t and test-help.t On Python 3, docstrings are converted back to utf-8 bytes, which practically disables the "if type(message) is pycompat.unicode" hack in gettext(). Let's add one more workaround for the Py3 path.

crecord: make enter move cursor down to the next item of the same type Let's replace experimental.spacemovesdown with a separate key: Enter, since it wasn't used for anything in crecord. Not sure if '\n' works on Windows though. nextsametype() strictly only moves to items of the same type as the current item. This, for example, allows to go over individual lines in a diff and skip hunk and file headers (which would toggle multiple lines).

py3: fix infinitepush extension tests Differential Revision: https://phab.mercurial-scm.org/D5078

py3: build help of compression engines in bytes Removes "b''" from help.

py3: do I/O in bytes in test-help.t

tests: accept slightly different zip file in Python 3 I added some `unzip -t` here and I *think* the only change is from Python 3 having more data in the zip file headers or something. Sigh. Differential Revision: https://phab.mercurial-scm.org/D5075

webcommands: use stringutil.pprint() to repr invalid archive types Differential Revision: https://phab.mercurial-scm.org/D5074

archival: don't try and fsdecode non-{bytes,str} objects This function accepts both bytes and file-like objects. Differential Revision: https://phab.mercurial-scm.org/D5073

tests: fix last failure in test-tools.t Differential Revision: https://phab.mercurial-scm.org/D5072

run-tests: run tests with as many processes as cores by default This seems like a useful default behavior so tests run faster by default* * Except in special circumstances where the OS/filesystem doesn't scale well to many CPU cores (like APFS *cough* *cough*). Differential Revision: https://phab.mercurial-scm.org/D5071

run-tests: print number of tests and parallel process count This seems like a useful output message to have. I also sneak in a change to lower the parallel process count if it is larger than the number of tests, as that makes no sense and output saying we're running more tests in parallel than there exists tests would be wonky. Differential Revision: https://phab.mercurial-scm.org/D5070

releasenotes: use stringutil.wrap() instead of handcrafted TextWrapper wrapper It's silly to splitlines() a joined string, but we don't care the performance here.

match: optimize matcher when all patterns are of rootfilesin kind Internally at Google, we use narrowspecs with only rootfilesin-kind patterns. Sometimes there are thousands of such patterns (i.e. thousands of tracked directories). In such cases, it can take quite long to build and evaluate the resulting matcher. This patch optimizes matchers that have only patterns of rootfilesin so it instead of creating a regular expression, it matches the given file's directory against the set of directories. In a repo with ~3600 tracked directories, it takes about 1.35 s to build the matcher and 2.7 s to walk the dirstate before this patch. After, it takes 0.04 s to create the matcher and 0.87 s to walk the dirstate. It may be worthwhile to do similar optimizations for e.g. patterns of type "kind:", but that's not a priority for us right now. Differential Revision: https://phab.mercurial-scm.org/D5058

churn: use integer division consistently This results in slight output changes, but it's at least consistent between Python 2 and 3. Since the output is just bar graphs anyway, I'm content with the changes. Differential Revision: https://phab.mercurial-scm.org/D5063

churn: fix stack traces on Python 3 Differential Revision: https://phab.mercurial-scm.org/D5062

py3: moar passing tests Differential Revision: https://phab.mercurial-scm.org/D5055

py3: one new passing tests Differential Revision: https://phab.mercurial-scm.org/D5006