Added signature for changeset 956ec6f1320d

Added tag 4.8rc0 for changeset 956ec6f1320d

merge to stable for 4.8 release freeze

shortest: never emit 0-length prefix even if unique It turned out that the pure version of our code for finding the shortest unique nodeid prefix would return a 0-length string if that was unique (because there was at most one revision in the disambiguation set). That's kind of correct, but it can't be used as input, so we shouldn't return it. Let's just adjust the given minlength up to at least 1. This fixes test-template-functions.t, which was failing in pure mode. Differential Revision: https://phab.mercurial-scm.org/D5181

logtoprocess: sends the canonical command name to the subprocess One of the use-case of logtoprocess is to monitor command duration. With the current code, we only get whatever command name the user typed (either abbreviated or aliased). This makes analytics on the collected data more difficult. Stores the canonical command name in the request object. Pass the stored canonical name in the `req.ui.log("commandfinish", ...)` call as keyword argument to not break potential string formatting. Pass the value as the environment variable named `LTP_COMMAND` to the called script. Differential Revision: https://phab.mercurial-scm.org/D4820

logtoprocess: fix message formatting The logtoprocess used to try formatting the message using keyword options instead of always using the rest of the arguments. Update it to match blackbox behavior. Differential Revision: https://phab.mercurial-scm.org/D5180

profiling: move default mode to "real" time Mercurial operations involve a lot of disks or network access. These impact command runtime significantly and it seems important to report them in our default profiling output. Having the right default means that we don't forget them when asking people to produces profiling traces or when doing profiling ourselves. Moving to "real time" by default will remove the need to think about activating it on most occasions. The "CPU" time-based profiling is still accessible when necessary.

streamclone: abort when client needs to handle obsmarkers, but doesn't When client doesn't have any of obsolescence markers exchange capabilities, then it's safe to say it can't handle obsmarkers. However, if it understands even one format version, then stream clones are fine -- client can use "obsmarkers" bundle2 part.

streamclone: include obsstore file into stream bundle if client can read it

setup: build exewrapper with Unicode support on py3 I didn't see a compiler switch documented anywhere, but I diffed the command line for full VC++ project when toggling between MBCS and Unicode. This is all they do.

exewrapper: convert to _tcsxxx functions for Unicode compatability This fixes more than 50 tests on py3 on Windows when enabled, mostly hooks and such that invoked `hg` directly. 187 left to go. I skipped doing the abort printing with Unicode because of apparent issues with MinGW [1]. It may be moot though, as MinGW isn't listed as a supported compiler after 3.4 [2]. [1] https://stackoverflow.com/questions/17700797/printf-wprintf-s-s-ls-char-and-wchar-errors-not-announced-by-a-compil [2] https://wiki.python.org/moin/WindowsCompilers

exewrapper: drop an unused variable

commands: restore compatibility for "^cmd" registration (issue6005) This is done at loading time, where ui is available.

exchangev2: support fetching shallow files history This commit teaches the exchangev2 client code to handle fetching shallow files data. Only shallow fetching of files data is supported: shallow fetching of changeset and manifest data is explicitly not yet supported. Previously, we would fetch file revisions for changesets that were received by the current pull operation. In the new model, we calculate the set of "relevant" changesets given the pull depth and only fetch files data for those changesets. We also teach the "filesdata" command invocation to vary parameters as needed. The implementation here is far from complete or optimal. Subsequent pulls will end up re-fetching a lot of files data. But the application of this data should mostly be a no-op on the client, so it isn't a big deal. Depending on the order file revisions are fetched in, revisions could get inserted with the wrong revision number relationships. I think the best way to deal with this is to remove revision numbers from storage and to either dynamically derive them (by reconstructing a DAG from nodes/parents) or remove revision numbers from the file storage interface completely. A missing API that we'll likely want to write pretty soon is "ensure files for revision(s) are present." We can kind of cajole exchangev2.pull() to do this. But it isn't very efficient. For example, in simple cases like widening the store to obtain data for a single revision, it is probably more efficient to walk the manifest and find exactly which file revisions are missing and to make explicit requests for just their data. In more advanced cases, asking the server for all files data may be more efficient, even though it requires sending data the client already has. There is tons of room for future experimentation here. And TBH I'm not sure what the final state will be. Anyway, this commit gets us pretty close to being able to have shallow and narrow checkouts with exchangev2/sqlite storage. Close enough that a minimal extension should be able to provide fill in the gaps until the code in core stabilizes and there is a user-facing way to trigger the narrow/shallow bits from `hg clone` without also implying using of the narrow extension... Differential Revision: https://phab.mercurial-scm.org/D5169

sqlitestore: support for storing revisions without their parents This commit kinda/sorta implements the equivalent of ellipsis nodes for the SQLite storage backend. Without implementing full blown ellipsis nodes (and the necessary support for them in the wire protocol), we instead teach the store to rewrite the p1 and p2 nodes to nullid when the incoming parent isn't in the local store. This allows servers to remain dumb and send the real parent and have the clients deal with the missing parent problem. This obviously isn't ideal because a benefit of ellipsis nodes is we can insert a fake parent to ellide missing changesets. But neither solution is ideal because it drops the original parent from storage. We could probably teach the SQLite store to retain the original parent and handle missing parents at read time. However, parent revisions are stored as integers and it isn't trivial to store an "empty" revision in the store yet, which would be necessary to represent the "missing" parent. The store is somewhat intelligent in trying to remove the missing parents metadata when the revision is re-added. But, revision numbers will be all messed up in that case, so I'm not sure it is worth it. At some point we'll likely want to remove the concept of revision numbers from the database and have the store invent them at index generation time. Or even better, we can do away with revision numbers from the file storage interface completely. We'll get there eventually... Differential Revision: https://phab.mercurial-scm.org/D5168

wireprotov2: support exposing linknode of file revisions When supporting shallow file storage, clients may fetch file revisions by changeset. But they may not readily know which changeset introduced a specific file revision. The "linknode" is used to record which changeset introduces which file revision. This commit teaches the "filedata" and "filesdata" wire protocol commands to expose the linknode for file revisions. The implementation is likely wrong when hidden changesets are in play, since the linknode may refer to a hidden changeset. We can deal with this problem later. Differential Revision: https://phab.mercurial-scm.org/D5167

localrepo: support marking repos as having shallow file storage Various operations against repositories need to know if repository storage is full or partial. For example, a checkout (including possibly a widening of a sparse checkout), needs to know if it can assume all file revisions are available or whether to look for missing revisions first. This commit lays the plumbing for doing that. We define a repo creation option that indicates that shallow file storage is desired. The SQLite store uses this creation option to add an extra repo requirement indicating file storage is shallow. A new repository feature has been added to indicate that file storage is shallow. The SQLite store adds this feature when the shallow file store requirement is present. Code can now look at repo.features to determine if repo file storage may be shallow and take additional actions if so. While we're here, we also teach the SQLite store to handle the narrow repo requirement, which gets added when making narrow clones. Differential Revision: https://phab.mercurial-scm.org/D5166

repository: teach addgroup() to receive data with missing parents The way the narrow extension works today, the server rewrites outgoing changegroup data to lie about parents when the parents data is missing. It adds the ellipsis flag to the revision so it can be recorded as such in the revlog. In the new wire protocol, such rewriting does not occur on the server (at least not yet anyway). Instead, it is up to the client to recognize when it has received a revision without its parents. This means rewriting will be performed on the client. Furthermore, the mechanism for storing a shallow revision may differ from store to store. For example, the revlog store uses the ellipsis flag to denote a revision's parents have been rewritten. But a non-revlog store may wish to store things differently. And, some stores may not even support receiving shallow revision data! Therefore, it makes sense for the store itself to be making decisions about what to do when they receive revision data without their parents. This commit teaches the addgroup() bulk insert method to accept a boolean argument that indicates whether the incoming data may lack parent revisions. This flag can be set when receiving "shallow" data from a remote. The revlog implementation of this method has been taught to rewrite the missing parent(s) to nullid and to add the ellipsis flag to the revision when a missing parent is encountered. But it only does this if ellipsis flags are enabled on the repo and the incoming data is marked as possibly shallow. An error occurs otherwise. Differential Revision: https://phab.mercurial-scm.org/D5165

commands: support passing depth to hg.clone() This will allow extensions to add --depth or other arguments to control depth fetching. Differential Revision: https://phab.mercurial-scm.org/D5164

filelog: add a hasnode() method (API) Missing in the file storage interface is the ability to query whether a specified value is a known node. This commit defines that interface member and implements it on the revlog and sqlite file stores. Storage unit tests have been added. The revlog implementation is a bit more complicated because index lookups don't consistently raise the same exception. For SQLite, we can simply look for a key in a dict. Differential Revision: https://phab.mercurial-scm.org/D5163

lfs: consult the narrow matcher when extracting pointers from ctx (issue5794) I added a testcase for lfs to all narrow tests, and the following failed: test-narrow-acl.t test-narrow-exchange.t test-narrow-patterns.t test-narrow-strip.t test-narrow-trackedcmd.t test-narrow-widen.t test-narrow.t The first two still have errors in the pretxnchangegroup on clone and (receiving a) push, which I'm still looking into (4d63f3bc1e1a fixed something in this area already). These two modified tests seem to cover the things that failed in the remaining narrow tests, i.e. `hg tracked` and `hg strip`, so I didn't bother enabling the testcases elsewhere. Maybe we should, but it's 68 tests total.

statprof: fix overflow while skipping boilerplate parts I got IndexError randomly because of stack[i] where i = len(stack).

statprof: fix indent level of fp.write() (issue6004) It was changed at 9d3034348c4f by mistake.

py3: stringify setupversion on Windows This was stringified a few lines above for non Windows platforms, but `version` remains bytes. The old code effectively undid the conversion, and triggered a warning in setuptools when building.

tests: add coverage for some untested areas of hgweb The fact that these mimetype guesses weren't blowing up anywhere on py3 prior to 9310037f0636 was the giveaway. The annotate function is a bit unusual in that it renders the page with a 500 in the middle, so I left the HTML output. For the other functions, checking the access log is enough.

statprof: update the name as the i increases (issue6003) 2864f8d3fcd6 while working on py3 fix, take out the name building out of the loop so we were not building the new stack-name for each i, rather we were using the first one again and again. The test changes shows the profile is now working. Differential Revision: https://phab.mercurial-scm.org/D5172

test: show more profile lines in test-profile.t This shows that we don't output anything after the first line and demonstrate issue6003. Differential Revision: https://phab.mercurial-scm.org/D5171

keepalive: use getattr to avoid AttributeErrors when vcr is in use Fixes test-phabricator.t. Differential Revision: https://phab.mercurial-scm.org/D5160

phabricator: do more of the VCR work in demandimport.deactivated() If I don't do this, VCR gets confused looking for pycurl and other libraries. I have no idea how this ever worked. Differential Revision: https://phab.mercurial-scm.org/D5159

tests: sleep longer in test-logtoprocess.t We should probably write some sort of helper that can wait N seconds for all specified values to appear in a file or something, but for now this will fix the FreeBSD buildbot. Differential Revision: https://phab.mercurial-scm.org/D5157

tests: fix pyflakes warning in test-duplicateoptions.py Differential Revision: https://phab.mercurial-scm.org/D5158

branchmap: avoid changelog and attribute lookups in replacecache() This should make things faster. I'm not sure which operations would benefit from it though. Maybe branchmap application on clone? Differential Revision: https://phab.mercurial-scm.org/D5162

branchmap: pass changelog into branchmap functions As part of building the branchmap, we loop over revs and call branchmap() or _branchmap(). Previously, these functions were accessing repo.changelog. We know from past experience that repo.changelog in loops is bad for performance. This commit teaches the branchmap code to pass a changelog instance into branchmap() and _branchmap() so we don't need to pay this penalty. On my MBP, this appears to show a speedup on a clone of the mozilla-unified repo: $ hg perfbranchmap --clear-revbranch ! base ! wall 21.078160 comb 21.070000 user 20.920000 sys 0.150000 (best of 3) ! wall 20.574682 comb 20.560000 user 20.400000 sys 0.160000 (best of 3) $ hg perfbranchmap ! base ! wall 4.880413 comb 4.870000 user 4.860000 sys 0.010000 (best of 3) ! wall 4.573968 comb 4.560000 user 4.550000 sys 0.010000 (best of 3) Differential Revision: https://phab.mercurial-scm.org/D5161

fuzz: move many initialization steps into LLVMFuzzerInitialize Doing this means that things we intentionally leak (eg type objects) no longer confuse AddressSanitizer, so now we can run the fuzzer MUCH longer. Differential Revision: https://phab.mercurial-scm.org/D5154

bundle2: fix broken compression engine assertion bundletype() is a function, so it needs to be called, and it is documented to return a 2-tuple. This code is untested, so that's why we haven't noticed the bad assertion. Differential Revision: https://phab.mercurial-scm.org/D5155

tests: glob over a difference between Windows 7 and Window 10 The error value is 11001 on Windows 10. I have no idea why it changed, but it seems unimportant.

py3: fix module imports in test-highlight.t The hash changes are because the *.py file is committed to the repo.

py3: fix module imports in tests, as flagged by test-check-module-imports.t I have no idea why these aren't flagged with python2. I excluded test-highlight.t for now to make this easier to review- the changed code is committed to a repo, which has cascading changes on the rest of the test. There's a mix of bytes and str in the imports dict of contrib/import-checker.py that crashed it half way through listing out these errors. I couldn't figure out how to fix that properly, so I was lazy and applied this on py3, to find the rest of the errors: diff --git a/contrib/import-checker.py b/contrib/import-checker.py --- a/contrib/import-checker.py +++ b/contrib/import-checker.py @@ -626,7 +626,12 @@ def find_cycles(imports): top.foo -> top.qux -> top.foo """ cycles = set() - for mod in sorted(imports.keys()): + def sort(v): + if isinstance(v, bytes): + return v.decode('ascii') + return v + + for mod in sorted(imports.keys(), key=sort): try: checkmod(mod, imports) except CircularImport as e:

lfs: don't add extension to hgrc after conversion (BC) This is in the spirit of bcf72d7b1524.

addremove: add "ui." prefix to message color keys I don't like fully-colorized status/warning messages, and I want to disable them at all. If we'd supported a syntax like 'color.ui.*=none', I could easily turn addremove.added/removed off as well as ui.error. This patch is just for that. Since addremove colors aren't released yet, which were added at ddc1da134772, there are no compatibility concerns.

update: clarify update() call sites by specifying argument names merge.update() takes a lot of parameters and I get confused all the time which is which. Differential Revision: https://phab.mercurial-scm.org/D5153

debugcommands: avoid stack trace from debugindexstats in pure mode This has been broken since I added it in d71e0ba34d9b (debugcommands: add a debugindexstats command, 2018-08-08). This patch also fixes the test. Differential Revision: https://phab.mercurial-scm.org/D5152

tests: fix up pure case of test-sqlitestore.t This is clearly what the line should read based on the "force to zlib" section below, so I'm guessing it just got overlooked during development. Differential Revision: https://phab.mercurial-scm.org/D5151

tests: don't emit false failures when sqlite3 is missing I'm honestly surprised we have buildbot coverage for this, but we do! Differential Revision: https://phab.mercurial-scm.org/D5150

py3: get around IOError variants in test-commandserver.t

py3: don't use traceback.print_exc() in commandserver.py It doesn't support a bytes stream on Python 3. This makes a traceback being sent by one frame, but that shouldn't matter.

py3: invalidate repository cache with system-string keys # skip-blame just a few r'' prefixes

py3: system-stringify file mode in commandserver.py # skip-blame just r'' prefixes

py3: alias next to __next__ in commandserver.py

py3: system-stringify list of attributes to be forwarded from commandserver.py # skip-blame just some r'' prefixes

py3: import StringIO from test utility to test-commandserver.t

py3: use bprint() helper in test-commandserver.t

py3: byte-stringify most literals in test-commandserver.t print() calls will be replaced by bprint(). # skip-blame just tons of b'' prefixes.

localrepo: ensure we properly %-format int in exception throw I'm not thrilled with this, but it'll do. Differential Revision: https://phab.mercurial-scm.org/D5107

py3: add a r'' prefix in mercurial/exchange.py # skip-blame because just r'' prefix This fixes test-narrow-acl.t on py3 which was broken by one of the earlier patches. Differential Revision: https://phab.mercurial-scm.org/D5149

py3: add 5 new passing tests to whitelist caught by buildbot Thanks to everyone who is putting efforts in making hg py3 compatible. Differential Revision: https://phab.mercurial-scm.org/D5148

py3: fix test-import-context.t

py3: restore perfstartup() prior to b456b2e0ad9f on Windows Otherwise the test errors out with: --- c:/Users/Matt/projects/hg_py3/tests/test-contrib-perf.t +++ c:/Users/Matt/projects/hg_py3/tests/test-contrib-perf.t.err @@ -184,6 +184,8 @@ $ hg perfrevrange $ hg perfrevset 'all()' $ hg perfstartup + 'b'c:' is not recognized as an internal or external command, + operable program or batch file. $ hg perfstatus $ hg perftags $ hg perftemplating

help: document the server capabilities added by the LFS extension I didn't bother marking these experimental because it references the extension that is already marked experimental.

py3: fix test-propertycache.py on Windows

commands: adjust metavariables as appropriate Apart from looking better in hg help command, these strings are also helpful when generating shell completions programmatically.

match: fix up a repr to not crash on Python 3 Differential Revision: https://phab.mercurial-scm.org/D5120

narrow: when widening, don't include manifests the client already has When widening, we already don't include the changelog (since f1844a10ee19) and files that the client already has (since c73c7653dfb9). However, we still include all manifests needed for the new narrowspec. When using flat manifests, that means we resend all the manifests even though the client necessarily has all of them. For tree manifests, we unnecessarily resend the root manifests and any subdirectory manifests that the client already has. This patch makes it so we no longer resend manifests that the client already has. It does so by passing an extra matcher to the changegroup packer and it uses that for filtering out directories matching the old matcher's visitdir(). For consistency between directories and files, it also makes the filtering of files look at both old and new matcher rather than passing in a diff matcher as we did before. Differential Revision: https://phab.mercurial-scm.org/D4895

tests: add test for widening from an empty clone Narrow clones that track no paths currently don't even include the root manifest (which is the only manifest when using flat manifests). That means that when we widen from such a clone, we need to make sure that we send the root manifest (and other manifests if using tree manifests). That currently works because we always resend all manifest that match the new narrowspec. However, we're about to stop resending manifests that the client already has and there's a risk of this breaking then, so let's add a test. Differential Revision: https://phab.mercurial-scm.org/D5143

subrepo: access status members by name instead of by position Taking my first Mercurial project closer to completion. Differential Revision: https://phab.mercurial-scm.org/D5144

revisions: when using prefixhexnode, ensure we prefix "0" Previously, if using `experimental.revisions.disambiguatewithin` (and it didn't include rev0), and '0' was the shortest identifier in that disambiguation set, we printed it as the shortest *without* a prefix. This was because we had logic to determine "if the prefix is a pure integer, but starts with 0, we don't need to prefix with 'x': 01 is not a synonym for revision #1", but didn't handle the case where prefix == 0 (which is a pure integer, and starts with 0... but it *is* "rev0"). Differential Revision: https://phab.mercurial-scm.org/D5113

store: pass matcher to store.datafiles() To get narrow stream clones working, we need a way to filter the storage files using a matcher. This patch adds matcher as an argument to store.walk() and store.datafiles() so that we can filter the files returned according to the matcher. Differential Revision: https://phab.mercurial-scm.org/D4850

streamclone: pass narrowing related info in _walkstreamfiles() This patch build a matcher using the include and exclude arguments we have in generatev2() and pass that matcher into _walkstreamfiles(). This will help us in filtering files we stream depending on the includes and excludes passed in by the user. Differential Revision: https://phab.mercurial-scm.org/D4851

streamclone: new server config and some API changes for narrow stream clones This patch introduces a new server config `experimental.server.stream-narrow-clones` which if set to True will advertise that the server supports narrow stream clones. This patch also pass on the includes and excludes from getbundle command to streamclone generation code. There is a test added to show that the includepats and excludepats are correctly passed. Upcoming patches will implement storage layer filtering for streamclones and then we can remove the temporary error and plug in the whole logic together to make narrow stream clones working. Differential Revision: https://phab.mercurial-scm.org/D5137

narrow: only send the narrowspecs back if ACL in play I am unable to think why we need to send narrowspecs back from the server. The current state adds a 'narrow:spec' part to each changegroup which is generated when narrow extension is enabled. So we are sending narrowspecs on pull also. There is a problem with sending the narrowspecs the way we are doing it right now. We add include and exclude as parameter of the 'narrow:spec' bundle2 part. The the len of include or exclude string increase 255 which is obvious while working on large repos, bundle2 generation code breaks. For more on that refer issue5952 on bugzilla. I was thinking why we need to send the narrowspecs back, and deleted the 'narrow:spec' bundle2 part generation code and found that only narrow-acl test has some failure. With this patch, we will only send the 'narrow:spec' bundle2 part if ACL is enabled because the original narrowspecs in those cases can be a subset of narrowspecs user requested. There are phase related output change in couple of tests. The output change shows that we are now dealing in public phases completely. So maybe sending the narrow:spec bundle2 part was preventing phases being exchanged or phase bundle2 data being applied. Differential Revision: https://phab.mercurial-scm.org/D4931

zsh_completion: add -l/--list flag for hg bookmarks completion Flags in parentheses are mutually exclusive. Logic is taken from commands.py: selactions = [k for k in ['delete', 'rename', 'list'] if opts.get(k)] if len(selactions) > 1: raise error.Abort(_('--%s and --%s are incompatible') % tuple(selactions[:2])) ... if rev and action in {'delete', 'rename', 'list'}: raise error.Abort(_("--rev is incompatible with --%s") % action) if inactive and action in {'delete', 'list'}: raise error.Abort(_("--inactive is incompatible with --%s") % action) Differential Revision: https://phab.mercurial-scm.org/D5142

zsh_completion: fix a couple of flags still not being perfect Differential Revision: https://phab.mercurial-scm.org/D5141

zsh_completion: use $_hg_remote_opts after it is defined Before this patch, zsh wouldn't complete --ssh, --remotecmd or --insecure for hg clone. While at it, replace --uncompressed by --stream. Differential Revision: https://phab.mercurial-scm.org/D5140

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.