histedit: Show file names in multiple line format

parser: fix crash by parsing "()" in keyword argument position A tree node can be either None or a tuple because x=("group", None) is reduced to x[1].

repoview: introduce a `experimental.extra-filter-revs` config The option define revisions to additionally filter out of all repository "view". The end goal is to provide and easy to way to serve multiple subset of the same repository using multiple "shares". The simplest use case of this feature is to have one view serving the public changesets and one view also serving the draft. This is currently achievable using the new `server.view` option introduced recently by Joerg Sonnenberger. However, more advanced use cases need more advanced definitions. For example some needs a view dedicated to some release branches, or view that hides security fixes to be released. Joerg Sonnenberger and I discussed this topic at the recent mini-sprint and the both of us have seen real life use cases for this. (This series got written during the same mini-sprint). The feature is fully functional, and use similar cache-fallback mechanism to ensure decent performance. However,there remaining room to ensure each share caches and hooks collaborate with each others. This will come at a later time once users start to actually test this feature on real usecase.

copies: filter out copies from non-existent source later in _chain() _changesetforwardcopies() repeatedly calls _chain(). That is very expensive because _chain() does lookups in the manifest. I hope to split up the function in two parts: 1) simple chaining, not considering end points, and 2) filter out files that don't exist in the end points (and ping-pong copies/renames). This patches gets us closer to that by moving the check for non-existent source later in the function. Now there are no more checks for "src" and "dst" in the first loop; all the filtering of invalid copies is done in the second loop. The code also looks much more consistent now. No measureable impact on `hg debugpathcopies 4.0 4.8`. That shouldn't be surprising since the only case we're doing more checks now is in case of chained copies/renames, which are quire rare in practice. Differential Revision: https://phab.mercurial-scm.org/D6277

copies: clarify mutually exclusive cases in _chain() with a s/if/elif/ If the 'b' dict has a rename from 'x' to 'y', it shouldn't be possible for 'x' to be both (a key) in 'a' and in 'src'. That would mean that 'x' is a file in the source commit and also a rename destination in the intermediate commit. But we currently don't allow renaming files onto existing files, so that shouldn't happen. So let's clarify that by using an "elif" instead of an "if". And if we did allow renaming files onto existing files, we should prefer to use the rename destination in the intermediate commit as source anyway. Differential Revision: https://phab.mercurial-scm.org/D6276

copies: delete a redundant cleanup step in _chain() The check is redundant since d5edb5d3a337 (copies: filter out copies when target is not in destination manifest, 2019-02-14). To test that hypothesis, I made this change in the commit that commit, but all tests still passed. I think the case was necessary before then, we just didn't have tests for it. Differential Revision: https://phab.mercurial-scm.org/D6275

copies: document cases in _chain() Differential Revision: https://phab.mercurial-scm.org/D6274

copies: ignore heuristics copytracing when using changeset-centric algos Differential Revision: https://phab.mercurial-scm.org/D6269

copies: move check for experimental.copytrace==<falsy> earlier I'm going to ignore experimental.copytrace when changeset-centric algorithms are required. This little refactoring makes that easier to add. Differential Revision: https://phab.mercurial-scm.org/D6268

copies: replace .items() by .values() where appropriate As pointed out by Pierre-Yves. Differential Revision: https://phab.mercurial-scm.org/D6266

copies: inline _computenonoverlap() in mergecopies() We now call pathcopies() from the base to each of the commits, and that calls _computeforwardmissing(), which does file prefetching (in the remotefilelog override). So the call to _computenonoverlap() is now pointless (the sets of files from _computenonoverlap() are subsets of the sets of files from _computeforwardmissing()). This somehow also fixes a broken remotefilelog test. Differential Revision: https://phab.mercurial-scm.org/D6256

copies: calculate mergecopies() based on pathcopies() When copies are stored in changesets, we need a changeset-centric version of mergecopies() just like we have a changeset-centric version of pathcopies(). I think the natural way of thinking about mergecopies() is in terms of pathcopies() from the base to each of the commits. So if we can rewrite mergecopies() based on two such pathcopies() calls, we'll get the changeset-centric version for free. That's what this patch does. A nice bonus is that it ends up being a lot simpler. mergecopies() has accumulated a lot of technical debt over time. One good example is the code for dealing with grafts (the "partial/incomplete/dirty" stuff). Since pathcopies() already deals with backwards renames and ping-pong renames, we get that for free. I've run tests with hard-coded debug logging for "fullcopy" and while I haven't looked at every difference it produces, all the ones I have looked at seemed reasonable to me. I'm a little surprised that no more tests fail when run with '--extra-config-opt experimental.copies.read-from=compatibility' compared to before this patch. This patch also fixes the broken cases in test-annotate.t and test-fastannotate.t. It also enables the part of test-copies.t that was previously disabled exactly because mergecopies() needed to get a changeset-centric version. One drawback of the rewritten code is that we may now make remotefilelog prefetch more files. We used to prefetch files that were unique to either side of the merge compared to the other. We now prefetch files that are unique to either side of the merge compared to the base. This means that if you added the same file to each side, we would not prefetch it before, but we would now. Such cases are probably quite rare, but one likely scenario where they happen is when moving from a commit to its successor (or the other way around). The user will probably already have the files in the cache in such cases, so it's probably not a big deal. Some timings for calculating mergecopies between two revisions (revisions shown on each line, all using the common ancestor as base): In the hg repo: 4.8 4.9: 0.21s -> 0.21s 4.0 4.8: 0.35s -> 0.63s In and old copy of the mozilla-unified repo: FIREFOX_BETA_60_BASE^ FIREFOX_BETA_60_BASE: 0.82s -> 0.82s FIREFOX_NIGHTLY_59_END FIREFOX_BETA_60_BASE: 2.5s -> 2.6s FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE: 3.9s -> 4.1s FIREFOX_AURORA_50_BASE FIREFOX_BETA_60_BASE: 31s -> 33s So it's measurably slower in most cases. The most significant difference is in the hg repo between revisions 4.0 and 4.8. In that case it seems to come from the fact that pathcopies() uses fctx.isintroducedafter() (in _tracefile), while the old mergecopies() used fctx.linkrev() (in _checkcopies()). That results in a single call to filectx._adjustlinkrev(), which is responsible for the entire difference in time (in my repo). So we pay a performance penalty but we get more correct code (see change in test-mv-cp-st-diff.t). Deleting the "== f.filenode()" in _tracefile() recovers the lost performance in the hg repo. There were are few other optimizations in _checkcopies() that I could not measure any impact from. One was from the "seen" set. Another was from a "continue" when the file was not in the destination manifest (corresponding to "am" in _tracefile). Also note that merge copies are not calculated when updating with a clean working copy, which is probably the most common case. I therefore think the much simpler code is worth the slowdown. Differential Revision: https://phab.mercurial-scm.org/D6255

tests: add test where copy source is deleted and added back This shows another difference between pathcopies() and mergecopies(): mergecopies() considers files that have been deleted and then added back as different files, but pathcopies() does not. Differential Revision: https://phab.mercurial-scm.org/D6330

merge with stable

Added signature for changeset 07e479ef7c96

Added tag 5.0 for changeset 07e479ef7c96

obsolete: drop the legacy `_enabled` variable Evolve 8.5.0 stopped setting this, and it would have been easier to figure out why TortoiseHg stopped allowing amends if it would have crashed on the missing variable.

discovery: only calculate closed branches if required The number of new closed branches is required for printing in error message. So let's only calculate them if we need to print error about new branches. Differential Revision: https://phab.mercurial-scm.org/D6314

hghave: deal with "rc" release Without this change, 5.0rc0 is not recognised as 5.0

branchcache: store the maximum tip in a variable inside for loop Instead of assigning self.tiprev multiple times in the for loop, and calling cl.node() on it, let's store that in a temporary variable and assign it in the end of loop. Differential Revision: https://phab.mercurial-scm.org/D6311

tests: demonstrate that rename is followed to wrong parent from merge This test case shows another way that copies are handled differently between `hg st` (pathcopies()) and `hg co -m` (mergecopies). The reason is that pathcopies() calls _tracefiles(), which checks that the file nodeid of an ancestor matches the file nodeid in the base commit. mergecopies() should probably be doing the same. Differential Revision: https://phab.mercurial-scm.org/D6323

test: demonstrate failure to follow rename with shadowed linkrev This shows a difference in handling of copies between `hg st` (pathcopies()) and `hg co -m`. The issue here is that mergecopies() uses the unadjusted linkrev() for determining when to stop walking ancestors. Differential Revision: https://phab.mercurial-scm.org/D6322

tests: slightly modify a linkrev test to prepare for expanding it The test case checks that the copy tracing code doesn't get confused by linkrevs when walking a file's ancestors. This patch chnages the test slightly so a second commit is grafted, thus producing a second "bad" linkrev. I'll use this in the next patch to demonstrate a bug. Differential Revision: https://phab.mercurial-scm.org/D6321

copies: process files in deterministic order for stable tests I also fixed a typo while at it. Differential Revision: https://phab.mercurial-scm.org/D6320

narrow: send specs as bundle2 data instead of param (issue5952) (issue6019) Before this patch, when ACL is involved, narrowspecs are send as bundle2 parameter for narrow:spec bundle2 part. The limitation of bundle2 parts are they cannot send data larger than 255 bytes. Includes and excludes in narrow are not limited by size and they can grow over 255 bytes. This patch introduces a new mandatory bundle2 part and send narrowspecs as data of that. The new bundle2 part is introduced to keep things cleaner and easy to distinguish related to backward compatibility. The part is mandatory because without server's narrowspec, the local ACL narrow repo won't work. This patch makes clients compatible with servers which have older versions. However I left a comment that we should drop the other bundle2 part soon as that's broken and people should not rely on that. I named the new bundle2 part 'Narrow:responsespec' because: 1) Capital 'N' to make it mandatory 2) 'Narrow:spec' cannot be used because bundle2 enforces that there should not be two different parts which resolve to same name when lowercased. 3) reponsespec clears that they are specs which are send as reponse by the server While I was here, I renamed `narrowhgacl` section to `narrowacl` as suggested by idlsoft@ and martinvonz@. Differential Revision: https://phab.mercurial-scm.org/D6310

py3: properly reject non-encoded strings given to hgweb

py3: handle meta-path finders that only use pre-python3.4 API

remotefilelog: add missing argument to hg.verify wrapper Differential Revision: https://phab.mercurial-scm.org/D6313

revsetbenchmark: track some simple use of "only" The only revset is quite useful and has various possible optimisation. tracking its timing seems useful.

inno: bump keyring to 18.0.1 to avoid AttributeError (issue6043) The error seems to be harmless, because it happens after closing the connection. For whatever reason, this isn't bundled with the Wix installer. https://github.com/jaraco/keyring/issues/386 https://bitbucket.org/Mekk/mercurial_keyring/issues/63/attributeerror-during-process-finish-with

push: added clear warning message when pushing closed branches(issue6080) Differential Revision: https://phab.mercurial-scm.org/D6038

branch: abort if closing branch from a non-branchhead cset This patch make sure that we abort if the user is trying to close a branch from a cset which is not a branch head. Changes in test file reflect the fixed behaviour. Differential Revision: https://phab.mercurial-scm.org/D6282

branch: add tests which shows branch can be closed from a non-branchhead cset This patch shows that we can close a branch even from a cset which is not a branch head. It was supposed to abort this operation. Next patch will be fixing the issue. Differential Revision: https://phab.mercurial-scm.org/D6281

phabricator: read more metadata from local:commits local:commits metadata can contain branch info, and 'rev' has been superseded by 'commit', see: https://github.com/phacility/arcanist/blob/83661809e532c3fe444a8bf7c7d6936e6377691b/src/repository/api/ArcanistMercurialAPI.php#L281 Differential Revision: https://phab.mercurial-scm.org/D6300

phabricator: don't assume the existence of properties of local:commits Not all the properties are guaranteed to be there, so if we don't check first we could die with a KeyError. Differential Revision: https://phab.mercurial-scm.org/D6299

phabricator: include branch in the diffproperty metadata This does not make Phabricator display the branch in web UI anywhere as that still need us to use creatediff API for that. However a future patch will make phabread use this to include the branch in its `hg import`-able output. Differential Revision: https://phab.mercurial-scm.org/D6297

tests: demonstrate `hg log -r . <file>` linkrev bug Differential Revision: https://phab.mercurial-scm.org/D6309

unionrepo: sync with repository API Differential Revision: https://phab.mercurial-scm.org/D6289

match: remove unused match.__iter__ implementation (API) Differential Revision: https://phab.mercurial-scm.org/D6305

fix: allow fixer tools to return metadata in addition to the file content With this change, fixer tools can be configured to output a JSON object that will be parsed and passed to hooks that can be used to print summaries of what code was formatted or perform other post-fixing work. The motivation for this change is to allow parallel executions of a "meta-formatter" tool to report back statistics, which are then aggregated and processed after all formatting has completed. Providing an extensible mechanism inside fix.py is far simpler, and more portable, than trying to make a tool like this communicate through some other channel. Differential Revision: https://phab.mercurial-scm.org/D6167

context: check file exists before getting data from _wrappedctx overlayworkingctx class is used to do in-memory merging. The data() function of that class has logic to look for data() in the wrappedctx if the file data in cache is empty and if the file is dirty. This assumes that if a file is dirty and cache has empty data for it, it will exists in the _wrappedctx. However this assumption can be False in case when we are merging a file which is empty in destination. In these cases, the backup file 'foo.orig' created by our internal merge algorithms will be empty, however it won't be present in _wrappedctx. This case will lead us to error like the one this patch is fixing. Let's only fallback to getting data from wrappedctx if cache has 'None' as data. Differential Revision: https://phab.mercurial-scm.org/D6308

tests: show IMM is broken when merging file empty in destination When we are doing in-memory merging, and we are merging a file which is empty in merge destination, it leads to error 'abort: xxx not found in manifest'. Next patch will fix this error. Differential Revision: https://phab.mercurial-scm.org/D6307

buildrpm: bump bundled Python version to 2.7.16 when building for centos{5,6} When building rpm packages for centos 5 and 6, we bundle a mercurial-specific version of Python 2.7 in /opt/python-hg. This change is analogous to 5e947367606c, and bumps the embedded Python version from 2.7.14 (released in 2017) to 2.7.16 (latest as of today).

merge with stable

phabricator: set local:commits time metadata as an int, not a string Same as arcanist does Differential Revision: https://phab.mercurial-scm.org/D6296

phabricator: use templatefilters.json in writediffproperties Instead of json.dumps, since it makes the code simpler and more readable. This would have been the better option for 8fd19a7b4ed6 but I wasn't aware of it at the time. Differential Revision: https://phab.mercurial-scm.org/D6295

commands: use byteskwargs() in verify() Otherwise Python 3 complains about the missing key. Differential Revision: https://phab.mercurial-scm.org/D6294

match: use raw strings to avoid illegal baskslash escape Python 3.8 was complaining about the invalid escape sequences. Let's use raw strings to avoid the warning and double baskslashes. Differential Revision: https://phab.mercurial-scm.org/D6293

revbranchcache: use context manager in _writerevs() to write to file The other _writenames() is a bit complicated to use context manager. Differential Revision: https://phab.mercurial-scm.org/D6292

revbranchcache: factor logic to write names and revs in separate functions Before this patch, the write function was so populated with upto 4 level of indentation, it was hard to understand what's going on. Differential Revision: https://phab.mercurial-scm.org/D6291

tests: make log style a little easier to read in test-copytrace-heuristics.t Revision numbers are much shorter and easier to read (especially compared to the full nodeids that were used here), so I switched to that. That's also what almost all the commands used (e.g. `hg rebase -s . -d 1`). I updated the two instances that used nodeids. I also made some other little cleanups to the log templates. Differential Revision: https://phab.mercurial-scm.org/D6279

tests: avoid cryptic nodeids in tests/test-rename-merge1.t These two nodeids had not been part of any output before, so one can't know which revision they refer to without adding something like `hg log` before them. It turned out that '.^' was equivalent for both of them, so that's what I replaced them with. Differential Revision: https://phab.mercurial-scm.org/D6280

tests: defines aliases for `hg log` calls in test-copytrace-heuristics.t This also makes the test cases more consistent since a few had missed the ":" in "changeset:" that the others used. Differential Revision: https://phab.mercurial-scm.org/D6278

rust-discovery: implementing and exposing stats() This time, it's simple enough that we can do it in all layers in one shot. Differential Revision: https://phab.mercurial-scm.org/D6233

rust-discovery: cpython bindings for the core logic As previously done with the ancestors submodule, testing for the bindings is provided from Python on a trivial case. Differential Revision: https://phab.mercurial-scm.org/D6232

rust-discovery: starting core implementation Once exposed to the Python side, this core object will avoid costly roundtrips with potentially big sets of revisions. This changeset implements the core logic of the object only, i.e., manipulation of the missing, common and undefined set-like revision attributes. Differential Revision: https://phab.mercurial-scm.org/D6231

rust-dagops: roots Unsuprisingly, the algorithm is much easier than for heads, provided we work on a set in the first place. To improve the signature, a trait for set-likes object would be useful, but that's not an immediate concern. Differential Revision: https://phab.mercurial-scm.org/D6230

rust-dagops: range of revisions This is a Rust implementation for what reachableroots2() does if includepath is True. The algorithmic details and performance notes are included in the documentation comment. Our main use case for now is a Rust counterpart of the partialdiscovery object, so we don't really need bindings yet. Differential Revision: https://phab.mercurial-scm.org/D6229

setup: tweak error message for Python 3 We now have beta support for Python 3. In my opinion, it isn't yet stable enough to allow `pip install Mercurial` to work with Python 3 out of the box: we don't want people accidentally using Mercurial with Python 3 just yet. But I do think we should be more friendly about informing people of their options. This commit tweaks the error message that users see when running setup.py with Python 3. We instruct them about the current level of Python 3 support, point them at the wiki for more info, and give them instructions on how to bypass the check. As part of this, I also changed which version value is printed, as we were printing a named tuple before.

setup: remove set and dict comprehensions Yuya observed in a recent review that it is worthwhile to keep setup.py parseable with Python 2.6 so a useful error message is seen when attempting to run with Python 2.6. This commit removes a set and dict comprehension so setup.py is parseable with Python 2.6.

branchcache: don't verify all nodes while writing nodes are verified either when they are added or used. In case of commits. we will load the whole branchmap, only verify nodes for the branch on which we are committing and then we write. However before this patch, writing the branchmap was validating all the nodes whereas it should not. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6290

setup: properly package distutils in py2exe virtualenv builds Our in-repo py2exe packaging code uses virtualenvs for managing dependencies. An advantage of this is that packaging is more deterministic and reproducible. Without virtualenvs, we need to install packages in the system Python install. Packages installed by other consumers of the system Python could leak into the Mercurial package. A regression from this change was that py2exe packages contained the virtualenv's hacked distutils modules instead of the original distutils modules. (virtualenv installs a hacked distutils module because distutils uses relative path lookups that fail when running from a virtualenv.) This commit introduces a workaround so py2exe packaging uses the original distutils modules when running from a virtualenv. With this change, `import distutils` no longer fails from py2exe builds produced from a virtualenv. This fixes the regression. Furthermore, we now include all distutils modules. Before, py2exe's module finding would only find modules there were explicitly referenced in code. So, we now package a complete copy of distutils instead of a partial one. This is even better than before. # no-check-commit foo_bar function name

narrow: also warn when not deleting untracked or ignored files Differential Revision: https://phab.mercurial-scm.org/D6265

setdiscovery: fix a few typos Differential Revision: https://phab.mercurial-scm.org/D6263

copies: delete debug message about "unmatched files new in both" Same reasoning as previous patch. Differential Revision: https://phab.mercurial-scm.org/D6251

copies: delete debug message about changes since common ancestor Same reasoning as previous patch. Differential Revision: https://phab.mercurial-scm.org/D6250

copies: delete debug message about search limit I'm about to rewrite mergecopies() and this message will no longer be emitted then. Let's remove the message now to remove a distraction from that patch. Differential Revision: https://phab.mercurial-scm.org/D6249

copies: move early return for "no copies" case a little earlier We can return before the block that prints debug messages. That block will not be run anyway when there are no copies. Differential Revision: https://phab.mercurial-scm.org/D6248

copies: fix up "fullcopy" with missing entries from "diverge" Similar to the previous patch, but this doesn't even affect tests. It does affect tests if you change them to turn on debug logging. I'm fixing it here so reviewers of the later rewrite patch can hard-code debug logging to be on and more easily compare test results. Differential Revision: https://phab.mercurial-scm.org/D6247

copies: fix up "fullcopy" with missing entries from "copy" This is just a workaround similar to the previous one. It will make it easier to follow later patches. Differential Revision: https://phab.mercurial-scm.org/D6246

merge: remove workaround for issue5020 As I explained in the previous commit, I think the filtering added there is a better fix for the issue, so the workaround from 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31) should no longer be needed. Differential Revision: https://phab.mercurial-scm.org/D6245

copies: don't include copies that are not in source in directory move I've been working on a rewrite of mergecopies(). I compared the output of the rewritten version with the current version. I noticed that between FIREFOX_NIGHTLY_59_END and FIREFOX_BETA_60_BASE in the mozilla-unified repo, there were many copies that the current version detected that the rewritten version did not. One example was js/src/gc/Iteration.h -> js/src/gc/PublicIterators.h. Then I realized that js/src/gc/Iteration.h doesn't even exist in FIREFOX_NIGHTLY_59_END. This patch adds a filtering step for the "fullcopy" dict. It turns out that that change also affects the test for issue5020 in test-merge-criss-cross.t. The 'dm' action no longer happens there. At first I thought that the test case change meant that this patch was broken, but I think it's actually correct tha the 'dm' action should not happen there. The result of the bid merge is still the same. I suspect this filtering is a better solution for the issue than 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31). I also suspect that it was broken just a few months earlier by a005c33d0bd7 (mergecopies: add logic to process incomplete data, 2016-10-04). Note that bid merge had been enabled for a few years at that point, since 19903277f035 (merge: use bid merge by default (BC), 2014-10-01). This patch is still just a workaround. It will be cleaned up soon (with the rewrite of mergecopies()). But doing this in a separate patch makes later patches easier to understand and gives a place to explain why this is changing. Differential Revision: https://phab.mercurial-scm.org/D6244

tests: add test for issue5343 (grafting with copies) It seems that issue5353 resulted in a lot of tests in test-graft.t, but the bug actually reported in that issue didn't get a test case. This patch adds one for the "move" and one for the "copy" version of it. I also added a "copy+modify" case, to show what should be a merge conflict. I didn't add one for the "backwards" version of it since the comment says that that was already covered by previous work. The tests added by this patch show the broken behavior (the bug is still open). I suspect the results returned from mergecopies() are not expressive enough to fix this issue: it has a dict for copies to merge with, but that can only give one more filename, but here we need two (one for the path on the remote side and one for the path in the merge base). I want to have it tested anyway since I'm about to refactor mergecopies(). Differential Revision: https://phab.mercurial-scm.org/D6242

chistedit: use context manager to set verbose ui I'm still not exactly sure why this is necessary -- perhaps setting it unconditionally would leak this setting in chg invocations. Regardless, this would have looked very out of place as compared to how this setting is done everywhere else, so at least for the sake of style, let's be consistent with the rest of the codebase.

setdiscovery: stop limiting the number of local head we initially send In our testing this limitation provides now real gain and instead triggers pathological discovery timing for some repository with many heads. See inline documentation for details. Some timing below: Mozilla try repository, (~1M revs, ~35K heads), discovery between 2 clones with 100 head missing on each side before: ! wall 1.492111 comb 1.490000 user 1.450000 sys 0.040000 (best of 20) ! wall 1.813992 comb 1.820000 user 1.700000 sys 0.120000 (max of 20) ! wall 1.574326 comb 1.573500 user 1.522000 sys 0.051500 (avg of 20) ! wall 1.572583 comb 1.570000 user 1.520000 sys 0.050000 (median of 20) after: ! wall 1.147834 comb 1.150000 user 1.090000 sys 0.060000 (best of 20) ! wall 1.449144 comb 1.450000 user 1.330000 sys 0.120000 (max of 20) ! wall 1.204618 comb 1.202500 user 1.146500 sys 0.056000 (avg of 20) ! wall 1.194407 comb 1.190000 user 1.140000 sys 0.050000 (median of 20) pypy (~100 heads, 317 heads) discovery between clones with only 42 common heads before: ! wall 0.031653 comb 0.030000 user 0.030000 sys 0.000000 (best of 25) ! wall 0.055719 comb 0.050000 user 0.040000 sys 0.010000 (max of 25) ! wall 0.038939 comb 0.039600 user 0.038400 sys 0.001200 (avg of 25) ! wall 0.038660 comb 0.050000 user 0.040000 sys 0.010000 (median of 25) after: ! wall 0.018754 comb 0.020000 user 0.020000 sys 0.000000 (best of 49) ! wall 0.034505 comb 0.040000 user 0.030000 sys 0.010000 (max of 49) ! wall 0.019631 comb 0.019796 user 0.018367 sys 0.001429 (avg of 49) ! wall 0.019132 comb 0.020000 user 0.020000 sys 0.000000 (median of 49) Private repository (~1M revs, ~3K heads), discovery from a strip subset, about 100 changesets to be pulled. before: ! wall 1.837729 comb 1.840000 user 1.790000 sys 0.050000 (best of 20) ! wall 2.203468 comb 2.200000 user 2.100000 sys 0.100000 (max of 20) ! wall 2.049355 comb 2.048500 user 2.002500 sys 0.046000 (avg of 20) ! wall 2.035315 comb 2.040000 user 2.000000 sys 0.040000 (median of 20) after: ! wall 0.136598 comb 0.130000 user 0.110000 sys 0.020000 (best of 20) ! wall 0.330519 comb 0.330000 user 0.260000 sys 0.070000 (max of 20) ! wall 0.157254 comb 0.155500 user 0.123000 sys 0.032500 (avg of 20) ! wall 0.149870 comb 0.140000 user 0.110000 sys 0.030000 (median of 20) Same private repo, discovery between two clone with 500 different heads on each side: before: ! wall 2.372919 comb 2.370000 user 2.320000 sys 0.050000 (best of 20) ! wall 2.622422 comb 2.610000 user 2.510000 sys 0.100000 (max of 20) ! wall 2.450135 comb 2.450000 user 2.402000 sys 0.048000 (avg of 20) ! wall 2.443896 comb 2.450000 user 2.410000 sys 0.040000 (median of 20) after: ! wall 0.625497 comb 0.620000 user 0.570000 sys 0.050000 (best of 20) ! wall 0.834723 comb 0.820000 user 0.730000 sys 0.090000 (max of 20) ! wall 0.675725 comb 0.675500 user 0.628000 sys 0.047500 (avg of 20) ! wall 0.671614 comb 0.680000 user 0.640000 sys 0.040000 (median of 20)

peer: introduce a limitedarguments attributes When set to True, it signal that the peer cannot receive too larges arguments and that algorithm must adapt. This should only be True for http peer that does not support argument passed as "post". This will be useful to unlock better discovery performance in the next changesets. I am using a dedicated argument because this is not really a usual "capabilities" things. An alternative approach would be to adds a "large-arguments" to all peer, but the http peers. That seemed a bit too hacky to me.

verify: also check full manifest validity during verify runs Before this changes, `hg verify` only checked if a manifest revision existed and referenced the proper files. However it never checked the manifest revision content itself. Mercurial is expecting manifest entries to be sorted and will crash otherwise. Since `hg verify` did not attempted a full restoration of manifest entry, it could ignore this kind of corruption. This new check significantly increases the cost of a `hg verify` run. This especially affects large repository not using `sparse-revlog`. For now, this is hidden behind the `--full` experimental flag.

verify: introduce an experimental --full flag The flag currently has no effect, see next changeset for details. We introduce the flag as experimental to keep the freedom of changing our mind on the final UI. Note: this patch highlight a small but in `hg help`. An option section is generated even if no option are visible.

verify: introduce a notion of "level" Some checks are slower than others, to help the user to run the checks he needs, we are about to introduce new flag to select faster vs deeper runs. This put the scaffolding in place to do this.

tests: split out separate test for issue5020 The test was added to the existing setup in 41f6af50c0d8 (merge: fix crash on criss cross merge with dir move and delete (issue5020), 2017-01-31). I'm about to make a change that affects that test and it's much easier to follow if the test case for issue5020 is a separate test case. The separate test case is based on what mpm provided in comment 12 on the issue. `hg diff -r 41f6af50c0d8^ tests/test-merge-criss-cross.t` after this patch is pretty small (besides the added test). It's probably easier for reviewers to look at that than to try to understand the diff itself (I don't understand it). Differential Revision: https://phab.mercurial-scm.org/D6243

tests: avoid a rename/delete conflict when updating in test-narrow-update.t After the upcoming rewrite of mergecopies(), this test would otherwise (accurately) start warning about "inside/f1 was deleted and renamed". Differential Revision: https://phab.mercurial-scm.org/D6254

tests: delete unused function in test-rename-merge2.t Differential Revision: https://phab.mercurial-scm.org/D6253

tests: make merge conflicts explicit in `hg annotate` tests We were using `true` as merge tool. I think it makes the test easier to understand if we make the conflicts explcit. It also papered over a conflict that shouldn't have been a conflict (just a bug in copy tracing). I've marked that "BROKEN". Differential Revision: https://phab.mercurial-scm.org/D6252

narrow: make warning about possibly dirty files respect ui.relative-paths Differential Revision: https://phab.mercurial-scm.org/D6264

merge: forgot to pull before release These two changes should be part of 5.0, but we are fine leaving them out of the RC.

Added signature for changeset 4a8d9ed86475

Added tag 5.0rc0 for changeset 4a8d9ed86475

merge: default into stable for release candidate

debugdiscovery: include the number of heads in all sets We already displayed information about heads of the common set that are either local or remote heads. We now also do so for heads of the common set that are both local and remote heads too. This is useful because various step in the set discovery algorithm have head specific optimizations.

recover: add a --[no-]verify flag For trivial cases, the cost of the verify run after `hg recover` is getting in the way. In addition for very large repositories, the cost is simply too high to be paid, making `hg recover` an unusable commands. We introduce a --verify flag, set by default. If is automatically associated with a --no-verify flag that one can use to skip the verify step. We might consider changing the default behavior in the future. However this is out of scope for this series.

bundle2: handle compression in _forwardchunks _forwardchunks is used to compensate for getbundle protocol deficits. Since it transparently decodes the payload, it also needs to remove the corresponding compression parameter in case the server decides to send one. This the wire protocol part of issue 5990. Differential Revision: https://phab.mercurial-scm.org/D6182

changelog: parse copy metadata if available in extras This lets read back the copy metadata we just started writing. There are still many places left to teach about getting the copy information from the changeset, but we have enough ({file_copies}, specifically) that we can add it now and have some test coverage of it. Differential Revision: https://phab.mercurial-scm.org/D6186

copies: add config option for writing copy metadata to file and/or changset This introduces a config option that lets you choose to write copy metadata to the changeset extras instead of to filelog. There's also an option to write it to both places. I imagine that may possibly be useful when transitioning an existing repo. The copy metadata is stored as two fields in extras: one for copies since p1 and one for copies since p2. I may need to add more information later in order to make copy tracing faster. Specifically, I'm thinking out recording which files were added or removed so that copies._chaincopies() doesn't have to look at the manifest for that. But that would just be an optimization and that can be added once we know if it's necessary. I have also considered saving space by using replacing the destination file path by an index into the "files" list, but that can also be changed later (but before the feature is ready to release). Differential Revision: https://phab.mercurial-scm.org/D6183

revsetbenchmark: add some simpler revset for heads and roots This revset might leverage compiled code in the future so lets start to track them.

repoview: flag `server.view` as experimental Ideally, the non-experimental version of `experimental.extra-filter-revs` will cover the use case for `server.view=immutable` well enough than having to have this dedicated configuration. Since `server.view` is not part of any release, I would prefer to have it marked as experimental to avoid having it to support it for ever.

repoview: move subsettable in a dedicated module The dictionary got moved in `branchmap` to avoid import cycle. However, we are about to needs it in repoview too. So we introduce a now module to define that that mapping.