tests: sniff for /usr/local/bin/gmake and use it in test-fuzz-targets.t This isn't as robust as it probably should be, but for now it'll get the job done on the buildbots. Differential Revision: https://phab.mercurial-scm.org/D5269

tests: stabilize test-inherit-mode.t on FreeBSD and macOS (issue6026) Symbolic links are funny permissions-wise, but on the linked issue Yuya has convinced me that we can ignore this permissions issue on macOS (FreeBSD allows setting permissions bits but ignores them) and we'll be in fine shape.

wireprotov2peer: wait for initial object before resolving future As part of rolling out wireprotov2 with redirect support, I encountered an edge case with regards to future resolution. Essentially, the initial response frame from the server did not fully decode the initial CBOR object. The frame wasn't marked as EOS. In the previous code, we resolved the future for the request to response.objects(), which mapped to the commandresponse instance which would eventually produce a redirect. Upon receiving subsequent data, the initial CBOR object containing the redirect would be decoded and we'd process the redirect. However, the future would already have been resolved with the initial commandresponse.objects() and the client iterating over the objects wouldn't receive any objects from the redirect because the redirect was populating a different commandresponse instance! This commit changes the logic so we don't resolve futures until the initial CBOR response object is fully decoded or until EOS occurs. In cases where there is an empty or partial frame associated with a redirect, the future will now resolve with the commandresponse containing the proper series of decoded objects.

wireprotov2peer: always return a bool from _processredirect() Without this, we may stop servicing the redirect response if the future has already been resolved. And the future will often be resolved very early, since many consumers iterate the decoded CBOR object stream and expect data to lazily arrive.

tests: stabilize the recent checkexec changes on Windows This goes with bd0874977a5e.

checkexec: create destination directory if necessary Since 460733327640, a "share" use the cache of the source repository. A side effect is that no `.hg/cache` directory exists in the "share" anymore. As a result, the checkexec logic can't use it to create its temporary file and have to use the working copy for that. This is suboptimal, it pollutes the working copy and prevents them to keep the file around in cache. We do not want to use the cache directory for the share target, it might be on a different file system. So instead, we (try to) create the directory if it is missing. This is a simple change that fixes the current behavior regression on stable. On default, we should probably ensure the proper directories are created when initializing the repository. We should also introduce a 'wcache' directory to hold cache file related to the working copy. This would clarify the cache situation regarding shares. The tests catch a couple of other affected cases.

graft: do not try to skip rev derived from ancestor more than once (issue6024) We check 'x in revs' in other cases, so let's do the same. The test case credits to Tom Prince.

subrepo: print the status line before creating the peer for better diagnostics I ran into a problem where I tried updating to a different branch, and the process appeared to hang. It turned out that the subrepo revision wasn't available locally, and I must have originally cloned it from an `hg serve -S` on a machine that currently wasn't serving anything. It took 2+ minutes to timeout, and didn't mention what it was connecting to even then. There are a couple of other issues in this scenario too. - The repo is dirty after the failed checkout because the top level repo is updated first. We should probably make 2 passes- top down to pull everything needed, and then do an update once everything is in place. - Something must be reading .hgsubstate from wdir because if the same merge command is run after the timeout, a prompt is issued that the local and remote subrepo diverged, instead of hanging. But it lists the local version and remote version as having the same hash.

tests: allow for 100% of profiled time in sleep in test-profile.t I'm getting an annoying failure in this test on our builder, and I *think* what's happening is that the profiler is taking _just_ long enough to start that we're spending 100% of the profiled time in the sleep function, which was causing the leading space to not be printed since the 100 was in the first column of output. Differential Revision: https://phab.mercurial-scm.org/D5272

copystore: provide unit to ui.makeprogress()

verify: provide unit to ui.makeprogress()

tests: fix wireproto redirection test on systems without tls1.2 Our automated package builder has some ancient configuration that lacks modern TLS, which is how we noticed this. Tested: the test now passes on both macOS High Sierra (has tls1.2) and Ubuntu Trusty (which does not).

phabricator: ensure the command summaries are available in extension help Previously, `hg help phabricator` listed the 3 supported commands at the bottom of the extension help, but said "no help text available".

hgweb: cast bytearray to bytes PEP-3333 seems to indicate that bytes is the only allowed type that can be used to express the output of a WSGI application. And some WSGI environments seem to enforce this (mod_wsgi does). This commit universally casts bytearray instances to bytes to appease the WSGI specification. I found this because wireprotov2 is emitting bytearray instances. I'd like to keep things that way because the way it builds a data structure, bytearray is more efficient. I'd rather keep the low-level code efficient (and using bytearray) and cast at the edges than impose a performance penalty on code that may run outside WSGI contexts.

help: unjumble the list of default config values for `internals.config`

tweakdefaults: remove commands.resolve.mark-check=abort, it is too broken See issue6020 for the current case. I don't want to continue attempting to fix this on the stable branch, so I'm removing from tweakdefaults and will send fixes meant for the default branch and 4.9. Differential Revision: https://phab.mercurial-scm.org/D5225

resolve: when resolve.mark-check=abort, downgrade to warning if pats specified Previously, with --config resolve.mark-check=abort, running `hg resolve -m foo` would abort and emit a message saying to use --all. This command does not work, though: `hg resolve -m foo --all`, and it's really weird for --all to be the "--force" flag. My original goal with the option was to make it so that `hg resolve -m` (no filename arguments) was safer, which is why --all is used; in my mind, `hg resolve -m foo` should always mark it as resolved, and `--all` is how you specify "all the files", so that's why I chose `hg resolve -m --all` as the way out of `hg resolve -m` aborting. This commit makes all of this work the way it was meant to in my head :) Differential Revision: https://phab.mercurial-scm.org/D5218

Added signature for changeset a91a2837150b

Added tag 4.8 for changeset a91a2837150b

rust: fix signature of rustlazyancestors_init() function Obviously, sizeof(int) != mem::size_of::<usize>() on amd64, though the argument would be passed in 64-bit register anyway.

tests: require SQLite 3.8.3+ as sqlitestore relies on "WITH" clause The test fails on gcc112 because the SQLite is too old. https://sqlite.org/changes.html#version_3_8_3

relnotes: various tweaks for release notes Stop filtering out commits that are expected to be covered by releasenotes extension: now we want two lists, one for WhatsNew and one for ReleaseX.Y. Use `only(stoprev, startrev)` to make `relnotes -h` output be actually true about what revisions are included. More filter rules, mostly obvious. More classifying rules to have less things in "unsorted". Looks like nargs=1 was just making args.startrev and args.stoprev be lists for no reason. BC and API sections are renamed to what we're using on the WhatsNew page, and also just skipped if empty.

delta: skip "empty delta" optimisation for non-general case (issue6006) Non-general delta repository cannot delta against anything than prev. So even if the delta to prev is empty we should use it. This is similar to the change made in bafa1c4bb7a8. Differential Revision: https://phab.mercurial-scm.org/D5201

narrow: fix copies._fullcopytracing() narrowspec filtering in graft case I broke this too in 707c3804e607 (narrow: move copies overrides to core, 2018-09-28). Hopefully I'm done fixing things broken by that commit now. Differential Revision: https://phab.mercurial-scm.org/D5213

tests: demonstrate broken copies._fullcopytracing() Turns out copies._fullcopytracing() was also broken. Differential Revision: https://phab.mercurial-scm.org/D5212

narrow: make copies.pathcopies() filter with narrowspec again I broke this in 707c3804e607 (narrow: move copies overrides to core, 2018-09-28). Differential Revision: https://phab.mercurial-scm.org/D5203

tests: demonstrate broken copies.pathcopies() Differential Revision: https://phab.mercurial-scm.org/D5202

setup: explain to distutils how we write rc versions When we use a rc version number (e.g. 4.8rc0), bdist_msi is using distutils.StrictVersion to parse it into a tuple of numbers. By default, StrictVersion.version_re only recognizes [ab] for alpha/beta, where mercurial may use '-rc' or 'rc'. This change makes StrictVersion parse correctly our version numbers, so that bdist_msi doesn't fail on rc versions.

changegroup: restore default node ordering (issue6001) Changeset db5501d9 changed the default node ordering from "storage" to "linearize". While the new API is more explicit and cleaner, the "linearize" order is problematic on certain repositories like netbeans where it makes bundling slower the more nodes we bundle. Pushing and pulling 100 changesets was ~20% slower and pushing and pulling 1000 changesets was ~600% slower. A very quick analysis of profile traces showed that the pull operation was taking more time creating the delta. Putting back the old default order seems to be the safe option. With more time during the next cycle, we can understand better the impact of sorting with the DAG order by default, the source of the regression and how to mitigate it. /!\ We are still waiting for the full performance impact but with this patch, bundling and pulling locally (not on the performance workstation) 1000 changesets on the netbeans repository is as fast as before the regression. Differential Revision: https://phab.mercurial-scm.org/D5196

changegroup: introduce an explicit linear sorting We still need to linearize the revisions in some cases, introduce an explicit `linear` sorting before changing back the default order. Differential Revision: https://phab.mercurial-scm.org/D5195

fix: disable use of thread-based worker getfixes() accesses to repo, changectx, filectx, etc., so I believe there are code paths triggering data race. Mercurial API isn't thread safe in general.

configitems: rename the config to prevent adding an alias in future Right now the config option looks like: [experimental.server] stream-narrow-clones= which does not match how config options are generally defined in core. So let's rename this to: [experimental] server.stream-narrow-clones= before the new release so that we don't have to add an alias in future for this. Differential Revision: https://phab.mercurial-scm.org/D5198

sparse-revlog: only refine delta candidates in the sparse case (issue6006) Starting with 5aef5afa8654, a valid delta parent might be "refined". This allows repository using sparse-revlog to produce better delta chain by using better intermediate snapshot base. However, this refining step was performed in all cases, including for repository not using sparse-revlog. This could produce a strange chain in the general delta case and corrupted repository in the non-general delta case. We now skip this step unless sparse-revlog is in use. In issue 6006, Yuya Nishihara provided a test case using an external repository, so we did not include it. Finding "laboratory" condition to reproduce this case and implementing an efficient test reproducing it is a bit tricky. We do not foresee to have the time to provide one by the release date. Differential Revision: https://phab.mercurial-scm.org/D5197

http: work around custom http client classes that refuse extra attrs I have no idea what is going on with our custom http client code at Google, but it chokes on these extra attributes we're tucking on http clients. Since it feels more than a little wrong to just stuff extra data on a client, let's degrade gracefully when the client class refuses the attributes.

crecord: make nextsametype() check that parent item exists (issue6009) Items that represent files in curses interface don't have parents.

help: describe what ui.tweakdefaults changes, concretely Currently, one has to look at the code. A couple things are suboptimal: - probably not translatable - lines don't get wrapped (a couple are a bit too long) but it seems to better this way than without help at all. Differential Revision: https://phab.mercurial-scm.org/D5187

logexchange: convert paths to unix when detecting the active path This fixes the problem in the tests[1] where Windows was showing the whole path as the remotename for local repositories. Somebody with a better understanding of this extension should probably take a deeper look. There may be other cases that need to be converted- specifically the `elif not instance` and the missing `else` cases in activepath(). I also noticed when adding debug prints that the absolute path is stored in the file, probably not normalized. (It's wrapped up in $TESTTMP.) [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/1042/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio

help: update the default value specified for `profiling.time-track` I tried conditionalizing this in a `.. container::` block, but that seemed to add an extra blank line between the main text and the parenthetical.

profiling: revert the default mode back to 'cpu' on Windows On Windows, os.times() only returns user and system times. Real elapsed time is 0. That results in no actual times reported, an end wall time of 0.000000, and seemingly randomly sorted stack frames. This at least provides test stability in test-profile.t. I kind of think that `default=pycompat.iswindows and 'cpu' or 'real'` would be a better way to set the default in configitems, but I didn't see any other examples of this, and thought maybe there's a reason for that. That might allow plugging the value into the help text automatically- the documented default wasn't updated in db0dba2d157d.

phase: add an archived phase This phase allows for hidden changesets in the "user space". It differs from the "internal" phase which is intended for internal by-product only. There have been discussions at the 4.8 sprint to use such phase to speedup cleanup after history rewriting operation. Shipping it in the same release as the 'internal-phase' groups the associated `requires` entry. The important bit is to have support for this phase in the earliest version of mercurial possible. Adding the UI to manipulate this new phase later seems fine. The current plan for archived usage and user interface are as follow. On a repository with internal-phase on and evolution off: * history rewriting command set rewritten changeset in the archived phase. (This mean updating the cleanupnodes method). * keep `hg unbundle .hg/strip-backup/X.hg` as a way to restore changeset for now (backup bundle need to contains phase data) * [maybe] add a `hg strip --soft` advance flag (a light way to expose the feature without getting in the way of a better UI) Mercurial 4.8 freeze is too close to get the above in by then. We don't introduce a new repository `requirement` as we reuse the one introduced with the 'archived' phase during the 4.8 cycle.

exewrapper: apply clang-format to silence test-check-clang-format.t

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.