unshelve: disable unshelve during merge (issue5123) As stated in the issue5123, unshelve can destroy the second parent of the context when tried to unshelve with an uncommitted merge. This patch makes unshelve to abort when called with an uncommitted merge. See how shelve.mergefiles works. Commit structure looks like this: ``` ... -> pctx -> tmpwctx -> shelvectx / / second merge parent pctx = parent before merging working context(first merge parent) tmpwctx = commited working directory after merge(with two parents) shelvectx = shelved context ``` shelve.mergefiles first updates to pctx then it reverts shelvectx to pctx with: ``` cmdutil.revert(ui, repo, shelvectx, repo.dirstate.parents(), *pathtofiles(repo, files), **{'no_backup': True}) ``` Reverting tmpwctx files that were merged from second parent to pctx makes them added because they are not in pctx. Changing this revert operation is crucial to restore parents after unshelve. This is a complicated issue as this is not fixing a regression. Thus, for the time being, unshelve during an uncommitted merge can be aborted. (Details taken from http://mercurial.808500.n3.nabble.com/PATCH-V3-shelve-restore-parents-after-unshelve-issue5123-tt4036858.html#a4037408) Differential Revision: https://phab.mercurial-scm.org/D6169

wix: add functionality to inject additional Features into installer This is the last bit required to be able to glue extra configs etc into the installer. Differential Revision: https://phab.mercurial-scm.org/D6180

wix: add support for additional wxs files As with my previous change for an --extra-prebuiild-script, I'm assuming this is predominantly useful in an enterprise environment and am only adding this to wix and not also to inno install scripts. Differential Revision: https://phab.mercurial-scm.org/D6179

wix: add a hook for a prebuild script to inject extra libraries I need this to build packages for Google so we can bundle some extensions in the installed image. My assumption is that this is most interesting for the .msi images so I only wired it up there. I'm not thrilled with the interface this provides, but it was an easy way to retain debug messages on Windows while also having enough structure to know what lines are actually module names for py2exe. Still pending on my end: I need to bundle a couple of config files, and at least one data file. I'm open to advice on how to do those things, and how to do this better. Differential Revision: https://phab.mercurial-scm.org/D6164

compression: introduce an official `format.revlog-compression` option This option supersedes the `experiment.format.compression` option. The value currently supported are zlib (default) and zstd (if Mercurial was compiled with zstd support). The option gained an explicit reference to `revlog` since this is the target usage here. Different storage methods might require different compression strategies. In our tests, using zstd give a significant CPU usage improvement (both compression and decompressing) while keeping similar repository size. Zstd as other interresting mode (dictionnary, pre-text, etc…) that are probably worth exploring. However, just plain switching from zlib to zstd provide a large benefit.

compression: display compression level in debugformat Now that we have options to control the compression level, we teach `hg debugformat` about them. This is a useful information when comparing repositories. Note that we have no trace of the compression level used to store existing deltas. Actually, it would even varies from one delta to another. So we display the currently set value.

compression: introduce a `storage.revlog.zstd.level` configuration This option control the zstd compression level used when compressing revlog chunk. The usage of zstd for revlog compression has not graduated from experimental yet, but we intend to fix that soon. The option name for the compression level is more straight forward to pick, so this changesets comes first. Having a dedicated option for each compression engine is useful because they don't support the same range of values. I ran the same measurement as for the zlib compression level (in the parent changesets). The variation in repository size is stay mostly in the same (small) range. The "read/write" performance see smallish variation, but are overall much better than zlib. Write performance show the same tend of having better write performance for when reaching high-end compression. Again, we don't intend to change the default zstd compression level (currently: 3) in this series. However this is worth investigating in the future. The Performance comparison of zlib vs zstd is quite impressive. The repository size stay in the same range, but the performance are much better in all situations. Comparison summary ================== We are looking at: - performance range for zlib - performance range for zstd - comparison of default zstd (level-3) to default zlib (level 6) - comparison of the slowest zstd time to the fastest zlib time Read performance: ----------------- | zlib | zstd | cmp | f2s mercurial | 0.170159 - 0.189219 | 0.144127 - 0.149624 | 80% | 88% pypy | 2.679217 - 2.768691 | 1.532317 - 1.705044 | 60% | 63% netbeans | 122.477027 - 141.620281 | 72.996346 - 89.731560 | 58% | 73% mozilla | 147.867662 - 170.572118 | 91.700995 - 105.853099 | 56% | 71% Write performance: ------------------ | zlib | zstd | cmp | f2s mercurial | 53.250304 - 56.2936129 | 40.877025 - 45.677286 | 75% | 86% pypy | 460.721984 - 476.589918 | 270.545409 - 301.002219 | 63% | 65% netbeans | 520.560316 - 715.930400 | 370.356311 - 428.329652 | 55% | 82% mozilla | 739.803002 - 987.056093 | 505.152906 - 591.930683 | 57% | 80% Raw data -------- repo alg lvl .hg/store size 00manifest.d read write mercurial zlib 1 49,402,813 5,963,475 0.170159 53.250304 mercurial zlib 6 47,197,397 5,875,730 0.182820 56.264320 mercurial zlib 9 47,121,596 5,849,781 0.189219 56.293612 mercurial zstd 1 49,737,084 5,966,355 0.144127 40.877025 mercurial zstd 3 48,961,867 5,895,208 0.146376 42.268142 mercurial zstd 5 48,200,592 5,938,676 0.149624 43.162875 mercurial zstd 10 47,833,520 5,913,353 0.145185 44.012489 mercurial zstd 15 47,314,604 5,728,679 0.147686 45.677286 mercurial zstd 20 47,330,502 5,830,539 0.145789 45.025407 mercurial zstd 22 47,330,076 5,830,539 0.143996 44.690460 pypy zlib 1 370,830,572 28,462,425 2.679217 460.721984 pypy zlib 6 340,112,317 27,648,747 2.768691 467.537158 pypy zlib 9 338,360,736 27,639,003 2.763495 476.589918 pypy zstd 1 362,377,479 27,916,214 1.532317 270.545409 pypy zstd 3 354,137,693 27,905,988 1.686718 294.951509 pypy zstd 5 342,640,043 27,655,774 1.705044 301.002219 pypy zstd 10 334,224,327 27,164,493 1.567287 285.186239 pypy zstd 15 329,000,363 26,645,965 1.637729 299.561332 pypy zstd 20 324,534,039 26,199,547 1.526813 302.149827 pypy zstd 22 324,530,595 26,198,932 1.525718 307.821218 netbeans zlib 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans zlib 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans zlib 9 1,197,135,671 155,034,586 141.620281 678.297064 netbeans zstd 1 1,259,581,737 160,840,613 72.996346 370.356311 netbeans zstd 3 1,232,978,122 157,691,551 81.622317 396.733087 netbeans zstd 5 1,208,034,075 160,246,880 83.080549 364.342626 netbeans zstd 10 1,188,624,176 156,083,417 79.323935 403.594602 netbeans zstd 15 1,176,973,589 153,859,477 89.731560 428.329652 netbeans zstd 20 1,162,958,258 151,147,535 82.842667 392.335349 netbeans zstd 22 1,162,707,029 151,150,220 82.565695 402.840655 mozilla zlib 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla zlib 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla zlib 9 2,587,542,494 287,018,264 163.622338 739.803002 mozilla zstd 1 2,723,159,348 286,617,532 91.700995 570.042751 mozilla zstd 3 2,665,055,001 286,152,013 95.240155 561.412805 mozilla zstd 5 2,607,819,817 288,060,030 101.978048 505.152906 mozilla zstd 10 2,558,761,085 283,967,648 104.113481 497.771202 mozilla zstd 15 2,526,216,060 275,581,300 105.853099 591.930683 mozilla zstd 20 2,485,114,806 266,478,859 95.268795 576.515389 mozilla zstd 22 2,484,869,080 266,456,505 94.429282 572.785537

compression: introduce a `storage.revlog.zlib.level` configuration This option control the zlib compression level used when compression revlog chunk. This is also a good excuse to pave the way for a similar configuration option for the zstd compression engine. Having a dedicated option for each compression algorithm is useful because they don't support the same range of values. Using a higher zlib compression impact CPU consumption at compression time, but does not directly affected decompression time. However dealing with small compressed chunk can directly help decompression and indirectly help other revlog logic. I ran some basic test on repositories using different level. I am using the mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite. All tested repository use sparse-revlog and got all their delta recomputed. The different compression level has a small effect on the repository size (about 10% variation in the total range). My quick analysis is that revlog mostly store small delta, that are not affected by the compression level much. So the variation probably mostly comes from better compression of the snapshots revisions, and snapshot revision only represent a small portion of the repository content. I also made some basic timings measurements. The "read" timings are gathered using simple run of `hg perfrevlogrevisions`, the "write" timings using `hg perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and mozilla central). The timings are gathered on a generic machine, (not one of our performance locked machine), so small variation might not be meaningful. However large trend remains relevant. Keep in mind that these numbers are not pure compression/decompression time. They also involve the full revlog logic. In particular the difference in chunk size has an impact on the delta chain structure, affecting performance when writing or reading them. On read/write performance, the compression level has a bigger impact. Counter-intuitively, the higher compression levels improve "write" performance for the large repositories in our tested setting. Maybe because the last 5000 delta chain end up having a very different shape in this specific spot? Or maybe because of a more general trend of better delta chains thanks to the smaller chunk and snapshot. This series does not intend to change the default compression level. However, these result call for a deeper analysis of this performance difference in the future. Full data ========= repo level .hg/store size 00manifest.d read write ---------------------------------------------------------------- mercurial 1 49,402,813 5,963,475 0.170159 53.250304 mercurial 6 47,197,397 5,875,730 0.182820 56.264320 mercurial 9 47,121,596 5,849,781 0.189219 56.293612 pypy 1 370,830,572 28,462,425 2.679217 460.721984 pypy 6 340,112,317 27,648,747 2.768691 467.537158 pypy 9 338,360,736 27,639,003 2.763495 476.589918 netbeans 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans 9 1,197,135,671 155,034,586 141.620281 678.297064 mozilla 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla 9 2,587,542,494 287,018,264 163.622338 739.803002

compression: accept level management for zlib compression We update the zlib related class to be support setting the compression level. This changeset focus on updating the internal only. A way to configure this level will be introduced in the next changeset.

util: extract compression code in `mercurial.utils.compression` The code seems large enough to be worth extracting. This is similar to what was done for various module in `mercurial/utils/`. Since None of the compression logic takes a `ui` objet, issuing deprecation warning is tricky. Luckly the logic does not seems to have many external users.

merge: make "labels" argument to graft() optional, like it is for update() graft() just passes the argument on to update(), and update() doesn't require it, so graft() shouldn't either. Differential Revision: https://phab.mercurial-scm.org/D6175

revset: remove comment about linkrev workaround from user-facing docs I think the code is clear enough so we don't need to keep the comment at all (by now, most Mercurial developers are probably familiar with the linkrevs issues). Differential Revision: https://phab.mercurial-scm.org/D6176

shelve: let cmdutil.revert() take care of backing up untracked files cmdutil.revert() backs up untracked files, so I don't see a reason to do it shelve.mergefiles(). We have tests for this and they still pass. Differential Revision: https://phab.mercurial-scm.org/D6174

shelve: stop passing list of files to revert It seems to work just fine to not specify any files here. I suspect it looked the way it did for historical reasons. It apparently used to use merge instead of rebase until 1d7a36ff2615 (shelve: use rebase instead of merge (issue4068), 2013-10-23) and it makes sense to want to restrict the set of files then. I noticed this because of the files.extend(shelvectx.p1().files()). If the working copy was clean before, then shelvectx.p1() will be the working copy parent and that ended up adding all the files in that set. In our Google-internal Mercurial setup (including a FUSE) that was very noticeably slow when the working copy parent happened to have many files in large directories. This patch doesn't yet remove the call to shelvectx.p1().files(). We also use that set for deciding what to back up. I'm pretty sure it's safe to back up only the set of files we already back even if we no longer restrict the set of files to revert, so this patch should be safe on its own. Regardless, the next patch will delegate the backing-up to cmdutil.revert(). Incidentally, this also gets rid of a repo.pathto() that I had earlier wanted to get rid of. Differential Revision: https://phab.mercurial-scm.org/D6173

remotefilelog: prefetch files in deterministic order I have been troubleshooting some slowness in this area (it's unclear if it's the client or server that's to blame, but that's beside the point) and it's a lot easier to do troubleshoot if the files are prefetched in the same order each time. Differential Revision: https://phab.mercurial-scm.org/D6172

debugdiscovery: display time elapsed during the discovery step This is a useful information. Now that we perform more analysing after the discovery is done, it is worth have a more precise measurement. For serious timing analysis use `hg perfdiscovery`.

debugdiscovery: only list common heads on verbose The list of common heads is only part of the useful information. In addition on repository with many heads, the information is very not helpful (just fill a couple of screen with hash). As a result we hide it behind a --verbose flag.

debugdiscovery: drop duplicated information The old line informing about the local being a superset or subset of the remote is redundant with the newly introduced data. So we drop it.

debugdiscovery: display more statistic about the common set We display a lot more information now. Especially, we display the overlap between the common heads and the local/remote heads. There are various optimization geared toward heads, as a result, the less common the heads the more complex the discovery. Having this information easily accessible help when working on discovery.

debugdiscovery: small internal refactoring The part of the code displaying statistic is made independant from the one running the discovery. In the same do, the declaration of the discovery function is a bit simplified.

debugdiscovery: allow to select random seed during debugdiscovery run The randomness can lead to large timing difference, controling it is important.

discovery: move cl.hasnode outside of the for-loop IIUC, resolving attributes for changelog can lead to some overhead. So this patch moves that to outside of a for-loop. Differential Revision: https://phab.mercurial-scm.org/D6147

discovery: prevent deleting items from a dictionary Removing elements from Python dictionary is expensive. So let's prevent adding them instead. I added a newline to make code look a bit better. Differential Revision: https://phab.mercurial-scm.org/D6146

discovery: drop some unused sets Differential Revision: https://phab.mercurial-scm.org/D6145

discovery: prevent recomputing info about server and outgoing changesets We already iterate over the outgoing.missing above and lookup repo for them. So let's reuse info calculated at that time instead of recomputing that again. Also we calculate the set of remotebranches by doing set(remotemap), so let's reuse that again. Upcoming patches will clean things a bit more. Differential Revision: https://phab.mercurial-scm.org/D6144

crecord: draw on the whole screen When starting crecord, one can see that it has a small gap on the rightmost column which doesn't get used. This is in contrast to other interactive curses frontends such as chistedit. Disabling the displaying of the cursor allows drawing on the whole availabe area and thus some hacky code in align() could be removed. Differential Revision: https://phab.mercurial-scm.org/D6171

automation: perform tasks on remote machines Sometimes you don't have access to a machine in order to do something. For example, you may not have access to a Windows machine required to build Windows binaries or run tests on that platform. This commit introduces a pile of code intended to help "automate" common tasks, like building release artifacts. In its current form, the automation code provides functionality for performing tasks on Windows EC2 instances. The hgautomation.aws module provides functionality for integrating with AWS. It manages EC2 resources such as IAM roles, EC2 security groups, AMIs, and instances. The hgautomation.windows module provides a higher-level interface for performing tasks on remote Windows machines. The hgautomation.cli module provides a command-line interface to these higher-level primitives. I attempted to structure Windows remote machine interaction around Windows Remoting / PowerShell. This is kinda/sorta like SSH + shell, but for Windows. In theory, most of the functionality is cloud provider agnostic, as we should be able to use any established WinRM connection to interact with a remote. In reality, we're tightly coupled to AWS at the moment because I didn't want to prematurely add abstractions for a 2nd cloud provider. (1 was hard enough to implement.) In the aws module is code for creating an image with a fully functional Mercurial development environment. It contains VC9, VC2017, msys, and other dependencies. The image is fully capable of building all the existing Mercurial release artifacts and running tests. There are a few things that don't work. For example, running Windows tests with Python 3. But building the Windows release artifacts does work. And that was an impetus for this work. (Although we don't yet support code signing.) Getting this functionality to work was extremely time consuming. It took hours debugging permissions failures and other wonky behavior due to PowerShell Remoting. (The permissions model for PowerShell is crazy and you brush up against all kinds of issues because of the user/privileges of the user running the PowerShell and the permissions of the PowerShell session itself.) The functionality around AWS resource management could use some improving. In theory we support shared tenancy via resource name prefixing. In reality, we don't offer a way to configure this. Speaking of AWS resource management, I thought about using a tool like Terraform to manage resources. But at our scale, writing a few dozen lines of code to manage resources seemed acceptable. Maybe we should reconsider this if things grow out of control. Time will tell. Currently, emphasis is placed on Windows. But I only started there because it was likely to be the most difficult to implement. It should be relatively trivial to automate tasks on remote Linux machines. In fact, I have a ~1 year old script to run tests on a remote EC2 instance. I will likely be porting that to this new "framework" in the near future. # no-check-commit because foo_bar functions Differential Revision: https://phab.mercurial-scm.org/D6142

contrib: PowerShell script to install development dependencies Configuring a Windows machine to hack on Mercurial is a bit of work and it isn't documented very well. This commit introduces a PowerShell script to automate going from a fresh Windows install to an environment suitable for building Mercurial, its installers, and running tests. Differential Revision: https://phab.mercurial-scm.org/D6141

chistedit: change in-progress message Saying "running histedit" is an artifact of when chistedit was a separate thing from histedit. I found the message a bit confusing, since wasn't I running histedit from the beginning, just from the curses interface? The whole thing is now histedit, both the curses interface and the underlying procedure to apply a plan, so let's use a message that doesn't make a distinction.

perf: copyedit a few documentation strings Differential Revision: https://phab.mercurial-scm.org/D6170

shelve: add --keep to list of allowables

perf: introduce a `perf.run-limits` options This options make it possible to configure the number of run that the extensions will perform. This is useful for automated benchmark or for performance measurement that need better accuracy.

perf: pass limits as a function argument The function applying the limit has no access to the configuration. Therefore, some higher layer will have to pass it as argument. We do this in an independent change to clarify the next change.

perf: more flexible implementation for checking stop conditions We want to make this logic simpler to configure. The first step is to stop hard-coding every values.

perf: document perfparents

perf: document config options We have configuration, so we better document it.

tests: use "perf" as a the extension name in test-contrib-perf.t This is simpler and seems more "inline" with the name people usually use for this extensions.

shelve: do not update when keeping changes, just move the dirstate This is to leave the working directory unchanged. We reuse the match object as an optimisation.

shelve: refactor _shelvecreatedcommit's match object into calling site We might need to use this match object again to move the dirstate in case the user requested to `--keep` the changes.

shelve: new keep option Does nothing yet. The docstring describes what it will soon be doing.

diff: support diffing explicit files in subrepos Most other commands support implied recursion based on file names already.

fix: make the order of the work queue deterministic This makes any output generated during the parallel phase of execution stable if parallelism is disabled. This helps write tests like that in the future. Differential Revision: https://phab.mercurial-scm.org/D6166

fix: allow fixing untracked files when given as arguments It's more useful to fix the file than to silently avoid it when the user does this: hg fix --working-dir untracked-file We will still do nothing to ignored files, even if they are specified. This may be safer, given that such files can unexpectedly slip into the arguments via a shell glob or fileset. Differential Revision: https://phab.mercurial-scm.org/D6165

branchcache: have a hasnode function to validate nodes Upcoming patches will delay node validation until it's required. So we need to a way in branchcache class to check whether a node exists or node. Other options were making repo or changelog an attribute of branchcache object. But the branchcache depends on filters so I decided to pass a function object. Differential Revision: https://phab.mercurial-scm.org/D6157

branchcache: add attributes to track which nodes are verified Half of the cost of loading branchcache comes from verifiying all the nodes it has. We don't need to verify all the nodes in all the cases. Sometimes we need to verify only a set of nodes for a set of branches. We can ignore nodes of other branches as we are not going to read them. This patch introduces two attributes to branchcache class. _verifiedbranches is a set which will tell the branches for which it's head nodes are verified. _closedverified is a boolean which will tell whether all closednodes are verified or not. Another idea which I had was to keep a set of nodes which are verified, but it will be more ugly and difficult to track things on node level. Differential Revision: https://phab.mercurial-scm.org/D6156

branchcache: make entries a private attribute Differential Revision: https://phab.mercurial-scm.org/D6155

branchcache: introduce hasbranch() This will be used to check whether a branch exists or not. This will optimized in future. Differential Revision: https://phab.mercurial-scm.org/D6154

branchmap: drop branchcache.setdefault() (API) All the callers are updated to call setdefault of branchcache.entries Differential Revision: https://phab.mercurial-scm.org/D6153

branchcache: rename itervalues() to iterheads() The itervalues() exists because branchcache() had a dict interface. Since it no longer has a dict interface, it makes sense to have better function names. If a person does not understand how branchcache stores info, it will be hard for them to guess what itervalues() does. Differential Revision: https://phab.mercurial-scm.org/D6152

branchmap: remove the dict interface from the branchcache class (API) The current branchmap computation involves reading the whole branchmap from disk, validating all the nodes even if they are not required. This leads to a lot of time on repos which have large branchmap or a lot of branches. On large repos, this can validate around 1000's of nodes. On some operations, like finding whether a branch exists or not, we don't need to validate all the nodes. Or updating heads for a single branch. Before this patch, branchcache class was having dict interface and it was hard to keep track of reads. This patch removes the dict interface. Upcoming patches will implement lazy loading and validation of data and implement better API's. Differential Revision: https://phab.mercurial-scm.org/D6151

test-template: fix stdio mode on Windows Otherwise, CBOR data would be corrupted. Spotted by Matt Harbison.

samplehgrcs: update the list of suggested extensions Back in the day, this was color and pager, both of which are now default. Churn isn't that popular, but the other four below (obviously?) are.

samplehgrcs: clarify which lines should be uncommented The original wording has confused at least one person. Hopefully it's clearer this way. https://stackoverflow.com/questions/55288177/adding-hg-strip-to-hgrc-config-file

templatefilters: add {x|cbor} filter for custom CBOR output

template: add CBOR output format The whole output is wrapped as an array just like the other serialization formats. It's an indefinite-length array since the size is unknown while encoding. Maybe we can add 'cbor-stream' (and 'pickle-stream') as needed.

memfilectx: override copysource() instead of using dummy nodeid The "_copied" property in basefilectx is used by renamed() and copysource(). committablefilectx (which memfilectx subclasses) overrides renamed() and writes it in terms of copysource() instead of _copied. That means that the nodeid part of "_copied" is memfilectx is unused. Let's instead override copysource() too so we don't need the "_copied". Differential Revision: https://phab.mercurial-scm.org/D6159

memctx: rename constructor argument "copied" to "copysource" (API) It's just the path, not the nodeid, so "copysource" seems more appropriate. Differential Revision: https://phab.mercurial-scm.org/D6158

crecord: redraw the screen when starting up chunkselector Failure to do this can cause screen corruption like: <headerline> [X] filename.cc <several blank lines> <output from previous iteration of split that happened to be here> I believe this might only happen in some terminals, and maybe only when using the "alternate screen". Regardless of the exact conditions to reproduce, it should be safe to always clear it when starting up and is probably the correct thing to do anyway :) Differential Revision: https://phab.mercurial-scm.org/D6131

crecord: redraw the screen on ctrl-L This is the normal use of Ctrl-L, so I think this is going to be what most people expect it to do. We're keeping the adjustment of what line we're scrolled to as well. I believe both to be necessary to handle otherwise inescapable situations when we've got screen corruption or edge-cases during window resizing. Differential Revision: https://phab.mercurial-scm.org/D6130

crecord: completely redraw screen when coming back from editor Differential Revision: https://phab.mercurial-scm.org/D6129