perf: add a --from flag to perfmergecalculate Before this change, `perfmergecalculate` was always benchmarking the merge of the working copy with another revision. We can now benchmark the `mergecalculate` call for any arbitrary pair of revision.

merge with stable

py3: fix test-narrow* which started failing because of recent changes #skip-blame because just r'' prefix Differential Revision: https://phab.mercurial-scm.org/D6447

tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit Differential Revision: https://phab.mercurial-scm.org/D6368

context: add ctx.files{modified,added,removed}() methods Changeset-centric copy tracing is currently very slow because it often reads manifests. One place it needs the manifest is in _chain(), where it removes a copy X->Y if Y has subsequently gotten removed. I want to speed that up by keeping track directly in the changeset of which files are removed in the changeset. These methods will be similar to ctx.p[12]copies() in that way: they will either read from the changeset or calculate the information from the manifests otherwise. Note that these are different from ctx.{modified,added,removed}() on merge commits. Those functions always compare to p1, but the new ones compare to both parents. filesadded() means "file does not exist in either parent but exists now", filesremoved() means "file existed in either parent but does not exist now", and filesmodified() means "file existed in either parent and still exists". The set of files in ctx.files() is the union of the files from the three new functions (and the three new ones are all disjoint sets). Also note that uncommitted merges are weird as usual. The invariant mentioned above still holds, but the functions compare to p1 (and are thus identical to the existing methods). Differential Revision: https://phab.mercurial-scm.org/D6367

copies: split up _chain() in naive chaining and filtering steps The function now has two clearly defined steps. The first step is the actual chaining. This step is very cheap. The second step is filtering out invalid copies. This step is expensive. For changeset-centric copy tracing, I want to do the filtering step only at the end. This patch prepares for that. Differential Revision: https://phab.mercurial-scm.org/D6418

relnotes: document changed behavior of ui.origbackuppath pointing to file Differential Revision: https://phab.mercurial-scm.org/D6446

templatekw: move showfileadds() close to showfile{mods,dels}() Differential Revision: https://phab.mercurial-scm.org/D6370

py3: use range() instead of xrange() The latter does not exist on Python 3. This makes test-contrib-perf.t pass on Python 3 again. Differential Revision: https://phab.mercurial-scm.org/D6443

narrow: move heads close to common as they are closely related Differential Revision: https://phab.mercurial-scm.org/D6445

narrow: pass binary nodeids to generateellipsesbundle2() We generally work with binary nodeids and it's should be expected that new function gets the nodeids in binary form already. Differential Revision: https://phab.mercurial-scm.org/D6444

match: stabilize _rootsdirsandparents doctest Changeset c4b8f8637d7a tried to stabilize some matcher test by using a set. This did not work because the set order is not stable. To fix it, we post process the result to display a sorted version of the set.

narrow: factor out logic to build ellipses related b2parts in separate fn This will help us switch more cleanly to using wireprotocol commands instead of using exchange.pull() which exchanges more things then required. Differential Revision: https://phab.mercurial-scm.org/D6435

narrow: remove unrequired compat code for old versions of hg As the comment says, that if is only required for servers having hg version 3.1 and 3.2. Any client connecting having hg 3.1 or 3.2 locally and trying to use narrow should already be broken taking in account the changes which have been done since narrow moved to core. Differential Revision: https://phab.mercurial-scm.org/D6434

perf: make sure to explicitly disable any profiler after the first iteration The current code work, because of some edge behavior of the `profile` class. We make it explicit that the profiler is not in effect more than once.

test: add missing 'cd ..' to test case Differential Revision: https://phab.mercurial-scm.org/D6439

match: remove an obsolete comment about util.finddirs() Obsolete since 8e55c0c642c (util: make util.dirs() and util.finddirs() include root directory (API), 2017-05-16). Differential Revision: https://phab.mercurial-scm.org/D6433

match: de-flake test-doctest.py by not depending on util.dirs() order util.dirs() yields directories in arbitrary order, which has made test-doctest.py flaky. I think they have been flaky since d8e55c0c642c (util: make util.dirs() and util.finddirs() include root directory (API), 2017-05-16). Before that commit, I think util.dirs() would return at most one entry, so there was only one iteration order. This patch fixes the problem by making _rootsdirsandparents() return a set (whose __str__() is defined to be in sorted order, I believe). The only caller wanted a set anyway. Differential Revision: https://phab.mercurial-scm.org/D6432

perf: add an option to profile the benchmark section Running a perf command with --profile gather data for the whole command execution, including setup and cleanup. This can significantly alter the data. To work around this we introduce a new option, it trigger the profiling of only one iteration of the benchmarked section.

perf: add a `pre-run` option sometimes, the initial run is necessary to warm some cache that are not relevant for the current measurement. We add a new `perf.pre-run` option to specify a number of run of the benchmark logic that will happens before measurement are taken.

narrow: consider empty commits to be "inside the narrow spec" for templates It doesn't seem useful to exclude them, or harmful to include them. Users writing log templates using outsidenarrow as a predicate might consider it unexpected if their locally created empty drafts are treated as if they contained something outside the clone. Differential Revision: https://phab.mercurial-scm.org/D6414

rust-python3: useless python2 specific import This python27_sys import prevents building with python3, it had been previously removed in a5fa9140ce4c, but that has been since pruned Differential Revision: https://phab.mercurial-scm.org/D6415

rust-python3: compatibility fix for incoming PyLong On Python3, PyInt is PyLong and it doesn't have the `value()` method. Re upcasting to PythonObj as done here works, but we might prefer taking a PythonObj from the onset (would require more testing) Differential Revision: https://phab.mercurial-scm.org/D6397

py3: add one new passing test found by buildbot Differential Revision: https://phab.mercurial-scm.org/D6412

discovery: slowly increase sampling size Some pathological discovery runs can requires many roundtrip. When this happens things can get very slow. To make the algorithm more resilience again such pathological case. We slowly increase the sample size with each roundtrip (+5%). This will have a negligible impact on "normal" discovery with few roundtrips, but a large positive impact of case with many roundtrips. Asking more question per roundtrip helps to reduce the undecided set faster. Instead of reducing the undecided set a linear speed (in the worst case), we reduce it as a guaranteed (small) exponential rate. The data below show this slow ramp up in sample size: round trip | 1 | 5 | 10 | 20 | 50 | 100 | 130 | sample size | 200 | 254 | 321 | 517 | 2 199 | 25 123 | 108 549 | covered nodes | 200 | 1 357 | 2 821 | 7 031 | 42 658 | 524 530 | 2 276 755 | To be a bit more concrete, lets take a very pathological case as an example. We are doing discovery from a copy of Mozilla-try to a more recent version of mozilla-unified. Mozilla-unified heads are unknown to the mozilla-try repo and there are over 1 million "missing" changesets. (the discovery is "local" to avoid network interference) Without this change, the discovery: - last 1858 seconds (31 minutes), - does 1700 round trip, - asking about 340 000 nodes. With this change, the discovery: - last 218 seconds (3 minutes, 38 seconds a -88% improvement), - does 94 round trip (-94%), - asking about 344 211 nodes (+1%). Of course, this is an extreme case (and 3 minutes is still slow). However this give a good example of how this sample size increase act as a safety net catching any bad situations. We could image a steeper increase than 5%. For example 10% would give the following number: round trip | 1 | 5 | 10 | 20 | 50 | 75 | 100 | sample size | 200 | 321 | 514 | 1 326 | 23 060 | 249 812 | 2 706 594 | covered nodes | 200 | 1 541 | 3 690 | 12 671 | 251 871 | 2 746 254 | 29 770 966 | In parallel, it is useful to understand these pathological cases and improve them. However the current change provides a general purpose safety net to smooth the impact of pathological cases. To avoid issue with older http server, the increase in sample size only occurs if the protocol has not limit on command argument size.

tests: make the grep pattern in remotefilelog-gcrepack portable (issue6122) test-remotefilelog-gcrepack was using "\" to escape "|" in the grep pattern. The most of implementations ignore "\" when it is followed by "|", so the regex works. However, OpenBSD doesn't ignore "\" and considers "|" part of the text instead of create two branches. Neither of both behaviors violate POSIX. This change removes the unnecessary escape character and changes grep to egrep, so the extended regular expression works on every unix. This is part of the bug 6122. Tested on OpenBSD, GNU, FreeBSD, NetBSD, Solaris 11 and BusyBox. Credits to Todd C. Miller, Paul de Weerd and Ingo Schwarze for helping me with it.

help: document new "bookmarksinstore" requirement in internals.requirements Differential Revision: https://phab.mercurial-scm.org/D6413

absorb: fix interactive mode I didn't know existed While investigating a bug in `hg absorb -e` I unintentionally discovered `hg absorb --interactive` and its brokenness. This adds a test and restores the functionality. Note that this interface is still marked experimental, so we can change this to be more sophisticated in the future. Differential Revision: https://phab.mercurial-scm.org/D6411

tests: work around libressl being different about error strings (issue6122) As far as I can tell, this is the right behavior. Thanks to Alex Gaynor for checking what the string means by looking at libressl sources for me. Differential Revision: https://phab.mercurial-scm.org/D6410

merge with stable

templatekw: change default value of 'requires' to () Since we dropped support for the old-style template keywords, we no longer have to distinguish None (old-style) and an empty requirement (new-style).

commit: move sorting of added and removed files list to lower level localrepo.commitctx() has lists of all changed files, as well as lists of added and removed files. The list of all files is unsorted and changelog.add() will sort it. Let's also sort the lists of added and removed files at a lower level (manifestrevlog.add()) for consistency. It also seems safer to do it there, just before we write them to the store. That way other callers won't be able to create invalid commits (or whatever the consequence is) by passing in unsorted lists. Also, alternative storages may not care that the lists are sorted. I don't think this will be a performance problem (someone should have fixed the sorting in changelog.add() if it were). Differential Revision: https://phab.mercurial-scm.org/D6390

match: drop unnecessary adding of '' to set of dirs This breaks some tests for "rootfilesin:" in a pattern matcher even more, but that just shows how broken that case is. Differential Revision: https://phab.mercurial-scm.org/D6406

narrowcommands: drop unnecessary adding of '' for root directory It's now included by util.dirs(). Differential Revision: https://phab.mercurial-scm.org/D6405

copies: remove hack for adding root dir to util.dirs object Differential Revision: https://phab.mercurial-scm.org/D6404

util: make util.dirs() and util.finddirs() include root directory (API) This changes the behavior of test-origbackup-conflict.t so it no longer errors out when the backup path points to an existing file. Instead, it replaces the file by a directory. That seems reasonable to me. Differential Revision: https://phab.mercurial-scm.org/D6403

dirstate: drop workaround for '.' matching root directory The check was added in 31abcae33b4f (dirstate: do not ignore current directory '.' (issue 1078), 2008-04-05) to fix issue1078. Funnily enough, comment #2 on that issue mentions using '' instead of '.' to represent the root directory, just like my previous patch did. test-hgignore.t fails with this patch without the previous patch. Differential Revision: https://phab.mercurial-scm.org/D6402

match: use '' instead of '.' for root directory (API) I think '' is generally a better value for the root directory than '.' is. For example, os.path.join('', 'foo') => 'foo', while os.path.join('.', 'foo') => './foo'. This patch mostly makes it so we use '' internally in match.py. However, it also affects the API in visitdir(), visitchildrenset() and files(). The two former now also accept '' as input. I've updated the callers of these methods. I've also added a deprecation warning for passing '.' (for external callers). The only caller I could find that was affected by files() returning '' instead of '.' was in dirstate.walk(). I've updated that. The next few patches show some workarounds we can remove by using '' instead of '.'. Differential Revision: https://phab.mercurial-scm.org/D6401

dirstate: move special handling of files==['.'] together I think it makes it a little clearer to have the two conditions for files==['.'] near each other. Differential Revision: https://phab.mercurial-scm.org/D6400

convert: don't include file in "files" list if it's added in p2 If the file is from p2, we should clearly compare the flags to what they were in p2. Also note that manifest.flags('non-existent') unfortunately returns '' instead of erroring out. Differential Revision: https://phab.mercurial-scm.org/D6409

convert: demonstrate broken {files} list in merge commits with file flags When there is a merge in which the flags for a file from p2 is non-empty, `hg convert` will incorrectly include that in the changeset's files list. Differential Revision: https://phab.mercurial-scm.org/D6408

templater: drop support for old style keywords (API) These changes originated from several commits over a period of time, so I'm slightly unsure if this is correct. But the tests pass.

commands: drop support for legacy ^cmd registration (API)

extensions: drop support for extsetup() without `ui` argument (API)

relnotes: mention removed support for mixed log graph lines This adds release notes for 264a2cbb25d0 (graphmod: remove support for graph lines mixing parent/grandparent styles (BC), 2018-10-16). Differential Revision: https://phab.mercurial-scm.org/D6407

tests: fix test-clonebundles on recent openbsd I guess openbsd feels like it needs to stringify this errno in lowercase and omit the "host" part of "hostname. Okay. Reported in a big test diff talking about libressl, see 6122. I'm not flagging this because most of that issue is about a libressl string change, so this doesn't really make a big difference there. Differential Revision: https://phab.mercurial-scm.org/D6399

rust-python3: compatibility fix for integer conversion On python3, `to_py_object()` on the usize gives us a PyLong, whereas it is the generic `PyObject` already on python2, which fits the `py.None()` default value. Upcasting to `PyObject` explicitely in all cases solves the issue. Differential Revision: https://phab.mercurial-scm.org/D6396

rust: sort dependencies entries in Cargo.toml I should probably write a test to enforce this... Differential Revision: https://phab.mercurial-scm.org/D6398

py3: make contrib/testparseutil.py to work on str(unicodes) contrib/check-code work on unicodes and call functions from testparseutil.py which before this patch used to work on bytes. This path removes that inconsistency and make testparseutil.py work on unicodes. This makes test-check-code.t and test-contrib-check-code.t work on Python 3 again. Differential Revision: https://phab.mercurial-scm.org/D6391

rust-filepatterns: call new Rust implementations from Python This change adds the import to the `rust-cpython` bindings and uses them when appropriate. A wrapper function has been defined in the case of `_regex` to keep this patch simple. Differential Revision: https://phab.mercurial-scm.org/D6273

rust-filepatterns: add `rust-cpython` bindings for `filepatterns` This change adds the `rust-cpython` interface for top-level functions and exceptions in the filepatterns module. Contrary to the Python implementation, this tries to have finer-grained exceptions to allow for better readability and flow control down the line. Differential Revision: https://phab.mercurial-scm.org/D6272

rust-filepatterns: add a Rust implementation of pattern-related utils This change introduces Rust implementations of two functions related to pattern handling, all located in `match.py`: - `_regex` - `readpatternfile` These utils are useful in the long-term effort to improve `hg status`'s performance using Rust. Experimental work done by Valentin Gatien-Baron shows very promising improvements, but is too different from the current Mercurial core code structure to be used "as-is". This is the first - albeit very small - step towards the code revamp needed down the line. Two dependencies were added: `regex` and `lazy_static`. Both of them will be useful for a majority of the Rust code that will be written, are well known and maintained either by the Rust core team, or by very frequent contributors. Differential Revision: https://phab.mercurial-scm.org/D6271

exchange: don't take wlock if bookmarks are stored in .hg/store/ If bookmarks are stored in .hg/store/, there is no need for the wlock(). Differential Revision: https://phab.mercurial-scm.org/D6388

bookmarks: keep bookmarks in .hg/store if new config set Bookmarks storage consists of two parts: (1) the set of bookmarks and their positions, and (2) the current bookmark. The former can get updated by exchange, while the latter cannot. However, they are both stored in directly .hg/ and protected by repo.wlock(). As a result, ugly workarounds were needed. This patch introduces a new config option to store the set of bookmarks and their positions in .hg/store/ but still storing the current bookmark directory in .hg/. The config option only takes effect at repo creation time. It results in a new requirement being set. Differential Revision: https://phab.mercurial-scm.org/D6387

log: flag topo-sorted set as such This isn't required right now, but revs.istopo() should return True.

copies: fix duplicatecopies() with overlay context The reasoning for this check is in 78d760aa3607 (duplicatecopies: do not mark items not in the dirstate as copies, 2013-03-28). The check was then moved to workingfilectx in 754b5117622f (context: add workingfilectx.markcopied, 2017-10-15) and no corresponding check was added later when overlayworkingfilectx was added. Rather than adding the check there, this patch adds a more generic check on the callers side and removes the check in workingfilectx.markcopied(). Differential Revision: https://phab.mercurial-scm.org/D6380

tests: demonstrate crash when rebasing across copy with --collapse As reported by timeless. Differential Revision: https://phab.mercurial-scm.org/D6379

exthelper: add some semi-useful trace logs It'd be nice to make the trace functions a little better-named in the output, but I'm not sure how much better we can do without overhead. This at least lets you see if a single reposetup function is eating all the time or if it's spread over all of them. I needed this because Google's uber-extension has a long load time and I wasn't sure where the problem was. Differential Revision: https://phab.mercurial-scm.org/D6381

help: add missing blank line, making "revlog-compression" show up Differential Revision: https://phab.mercurial-scm.org/D6386

tests: fix share test to actually share the repo "repo2" is clearly meant to be a share from "repo1" but without sharing bookmarks. However, `hg unshare` was called in the repo, so it had become completely unrelated and thus not testing what it was supposed to test. Differential Revision: https://phab.mercurial-scm.org/D6385

tests: separate out bookmarks tests from test-share.t Differential Revision: https://phab.mercurial-scm.org/D6384

bookmarks: use vfs.tryread() instead of reimplementing it Differential Revision: https://phab.mercurial-scm.org/D6383

bookmarks: use context manager when writing files Differential Revision: https://phab.mercurial-scm.org/D6382

bisect: do not crash with rewritten commits

log: add config for making `hg log -G` always topo-sorted I (and everyone else at Google) have an log alias that adds graph mode and templating. I have another one that builds on the first and also restricts the set of revisions to only show those I'm most likely to care about. This second alias also adds topological sorting. I still sometimes use the first one. When I do, it very often bothers me that it's not topologically sorted (branches are interleaved). This patch adds a config option for always using topological sorting with graph log. The revision set is sorted eagerly, which seems like a bad idea, but it doesn't seem to make a big difference in the hg repo (150ms). I initially tried to instead wrap the user's revset in sort(...,topo), but that seemed much harder. Differential Revision: https://phab.mercurial-scm.org/D6331

log: remove an unnecessary "and opts.get('rev')" condition As Yuya pointed out, the condition is unnecessary since revs.isdescending() would be true if --follow without --rev. Differential Revision: https://phab.mercurial-scm.org/D6372

graphmod: remove support for graph lines mixing parent/grandparent styles (BC) Currently, if the configuration for a graph edge draw style has multiple bytes (at least on python2), it is interpreted as "this is a request to draw the line partially in the style of the parent, partially in the style of the grandparent". This precludes the configuration handling unicode characters (which trigger the `len > 1` check, at least on python2), and I believe was part of the reason that beautifygraph was written the way it was. Talking with the person who implemented this, it appears to have been to achieve feature parity with the rendering of the smartlog extension. I suspect that this isn't actually used outside of that situation, so I think that we can remove it without much issue. This will make it so that multi-character edges are possible, and render any existing configuration that uses this feature with these multiple characters. This is *not* going to adjust the width of everything to make it line up correctly, please see the test that's being modified in this changeset for an example of how the previous configuration now renders. Note also that the previous configuration seems to have been broken, or at least it was behaving in a really non-obvious way - it was avoiding the grandparent character(s) when it should have been displaying them! This is why so many "!" characters changed to "3."; I don't know if this was intentional. Differential Revision: https://phab.mercurial-scm.org/D5112

py3: add 5 new passing tests Differential Revision: https://phab.mercurial-scm.org/D6378

py3: add a r'' to prevent transformer adding b'' # skip-blame because just r'' prefix Differential Revision: https://phab.mercurial-scm.org/D6377

rust-dirstate: call parse/pack bindings from Python A future patch will need to address the issue of Rust module policy, to avoid having ugly duplicate imports and conditionals all over the place. As the rewrite of dirstate in Rust progresses, we will need fewer of those "contact points". Differential Revision: https://phab.mercurial-scm.org/D6350

rust-dirstate: add rust-cpython bindings to the new parse/pack functions This allows for Python code to call `parse/pack_dirstate` transparently. These bindings are heavy given the relatively simple task, as they are bound to implementation details of both the C and Python code. They will be slimmed down in future patches and eventually completely removed once more of the dirstate code has been refactored/rewritten in Rust. Both functions emulate the mutate-on-loop style of the Python and C implementations by looping over changed items in the compatibility layer, instead of at the core functions. Differential Revision: https://phab.mercurial-scm.org/D6349

rust-dirstate: add rust implementation of `parse_dirstate` and `pack_dirstate` Working towards the goal of having a complete Rust implementation of `hg status`, these two utils are a first step of many to be taken to improve performance and code maintainability. Two dependencies have been added: `memchr` and `byteorder`. Both of them have been written by reputable community members and are very mature crates. The Rust code will often need to use their byte-oriented functions. A few unit tests have been added and may help future development and debugging. In a future patch that uses `parse_dirstate` to stat the working tree in parallel - which neither the Python nor the C implementations do - actual performance improvements will be seen for larger repositories. Differential Revision: https://phab.mercurial-scm.org/D6348

changelog: define changelogrevision.p[12]copies for null revision Looks like I missed these in 5382d8f8530b (changelog: parse copy metadata if available in extras, 2017-12-27). `hg debugp[12]copies -r null` fails before this patch. Differential Revision: https://phab.mercurial-scm.org/D6376

copies: write empty entries in changeset when also writing to filelog When writing to both changeset and filelog (during transition), we don't want the reader to waste time by falling back to reading from the filelog when there is no copy metadata. Let's write out empty copy metadata instead (the read path is already prepared for this case). Thanks to Greg for pointing this out. Differential Revision: https://phab.mercurial-scm.org/D6306

rebase: hide help for revisions.Predicates._destautoorphanrebase

unshelve: add space to help

context: default to using branch from dirstate only in workingctx Same reasoning as previous commits: only the workingctx should know about the dirstate. committablectx now seems free of dirstate references. Differential Revision: https://phab.mercurial-scm.org/D6374

context: let caller pass in branch to committablectx.__init__() committablectx.__init__() currently looks up the branch from the dirstate unless it's passed in the extras. memctx.__init__() has a branch argument, but since committablectx.__init__() doesn't accept it, it lets that constructor look up the branch from the dirstate before it overwrites it, which seems awkward. Differential Revision: https://phab.mercurial-scm.org/D6366

context: move contents of committablectx.markcommitted() to workingctx Same reasoning as previous commits: this function updates the dirstate. By not updating the dirstate here, we also fix the close-head test. Differential Revision: https://phab.mercurial-scm.org/D6365

tests: demonstrate that close-head command updates working copy The help text for the command says "...it doesn't change the working directory", so I don't think this is intentional. Differential Revision: https://phab.mercurial-scm.org/D6364

context: move walk() and match() overrides from committablectx to workingctx Same reasoning as previous commit: these functions update the dirstate. Differential Revision: https://phab.mercurial-scm.org/D6363

context: move flags overrides from committablectx to workingctx These read from the dirstate, so they shouldn't be used in other subclasses. Differential Revision: https://phab.mercurial-scm.org/D6362

context: reuse changectx._copies() in all but workingctx This moves the dirstate-specific _copies() implementation from committablectx into workingctx where it should be (I think all dirstate-specific stuff should be moved into workingctx). The part of changectx._copies() that is for producing changeset-wide copy dicts from the filectxs is moved into basectx so it's reused by the other subclasses. The part of changectx._copies() that's about reading copy information from the changeset remains there. This fixes in-memory rebase (and makes `hg convert` able to write copies to changesets). Differential Revision: https://phab.mercurial-scm.org/D6219

overlayworkingctx: don't include added-then-deleted files in memctx If a file (such as a .orig file) is temporarily added to the overlayworkingctx and then deleted, it's still going to be in the _cache dict. In tomemctx(), we created the list of files from _cache.keys(), so the memctx.files() would include the temporary file. That was fine because the list of files was only used in localrepo.commitctx() (I think), where there's an extra filtering of incorrectly removed files (annotated with an inaccurate "update manifest" comment). I'd like to call memctx.files() in another case, but first we need to make it accurate. Differential Revision: https://phab.mercurial-scm.org/D6361

tests: demonstrate loss of changeset copy metadata on rebase Differential Revision: https://phab.mercurial-scm.org/D6360

overlaycontext: allow calling copydata() on clean context We should just report no copy if the context is clean. Differential Revision: https://phab.mercurial-scm.org/D6358

tests: demonstrate another failure with in-memory rebase and copies This is a similar to dd1ab72be983 (test: demonstrate crash with in-memory rebase and copies, 2019-03-14). The new failure started with 57203e0210f8 (copies: calculate mergecopies() based on pathcopies(), 2019-04-11). It happens in the call to mergemod.update() on rebase.py:1268 where we call mergemod.update() to graft a node. Since the mergecopies() rewrite, that calls _related() with the filectx from the overlaywctx instead of a filectx from the changectx where the file was last modified. Either should be fine, so I don't think that's a bug. Differential Revision: https://phab.mercurial-scm.org/D6357

commit: fix a typo ("form p1" -> "from p1") Differential Revision: https://phab.mercurial-scm.org/D6375

automation: initial support for running Linux tests Building on top of our Windows automation support, this commit implements support for performing automated tasks on remote Linux machines. Specifically, we implement support for running tests on ephemeral EC2 instances. This seems to be a worthwhile place to start, as building packages on Linux is more or less a solved problem because we already have facilities for building in Docker containers, which provide "good enough" reproducibility guarantees. The new `run-tests-linux` command works similarly to `run-tests-windows`: it ensures an AMI with hg dependencies is available, provisions a temporary EC2 instance with this AMI, pushes local changes to that instance via SSH, then invokes `run-tests.py`. Using this new command, I am able to run the entire test harness substantially faster then I am on my local machine courtesy of access to massive core EC2 instances: wall: 16:20 ./run-tests.py -l (i7-6700K) wall: 14:00 automation.py run-tests-linux --ec2-instance c5.2xlarge wall: 8:30 automation.py run-tests-linux --ec2-instance m5.4xlarge wall: 8:04 automation.py run-tests-linux --ec2-instance c5.4xlarge wall: 4:30 automation.py run-tests-linux --ec2-instance c5.9xlarge wall: 3:57 automation.py run-tests-linux --ec2-instance m5.12xlarge wall: 3:05 automation.py run-tests-linux --ec2-instance m5.24xlarge wall: 3:02 automation.py run-tests-linux --ec2-instance c5.18xlarge ~3 minute wall time to run pretty much the entire test harness is not too bad! The AMIs install multiple versions of Python. And the run-tests-linux command specifies which one to use: automation.py run-tests-linux --python system3 automation.py run-tests-linux --python 3.5 automation.py run-tests-linux --python pypy2.7 By default, the system Python 2.7 is used. Using this functionality, I was able to identity some unexpected test failures on PyPy! Included in the feature is support for running with alternate filesystems. You can simply pass --filesystem to the command to specify the type of filesystem to run tests on. When the ephemeral instance is started, a new filesystem will be created and tests will run from it: wall: 4:30 automation.py run-tests-linux --ec2-instance c5.9xlarge wall: 4:20 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem xfs wall: 4:24 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem tmpfs wall: 4:26 automation.py run-tests-linux --ec2-instance c5d.9xlarge --filesystem ext4 We also support multiple Linux distributions: $ automation.py run-tests-linux --distro debian9 total time: 298.1s; setup: 60.7s; tests: 237.5s; setup overhead: 20.4% $ automation.py run-tests-linux --distro ubuntu18.04 total time: 286.1s; setup: 61.3s; tests: 224.7s; setup overhead: 21.4% $ automation.py run-tests-linux --distro ubuntu18.10 total time: 278.5s; setup: 58.2s; tests: 220.3s; setup overhead: 20.9% $ automation.py run-tests-linux --distro ubuntu19.04 total time: 265.8s; setup: 42.5s; tests: 223.3s; setup overhead: 16.0% Debian and Ubuntu are supported because those are what I use and am most familiar with. It should be easy enough to add support for other distros. Unlike the Windows AMIs, Linux EC2 instances bill per second. So the cost to instantiating an ephemeral instance isn't as severe. That being said, there is some overhead, as it takes several dozen seconds for the instance to boot, push local changes, and build Mercurial. During this time, the instance is largely CPU idle and wasting money. Even with this inefficiency, running tests is relatively cheap: $0.15-$0.25 per full test run. A machine running tests as efficiently as these EC2 instances would cost say $6,000, so you can run the test harness a >20,000 times for the cost of an equivalent machine. Running tests in EC2 is almost certainly cheaper than buying a beefy machine for developers to use :) # no-check-commit because foo_bar function names Differential Revision: https://phab.mercurial-scm.org/D6319

automation: move image operations to own functions An upcoming commit will need this functionality with slightly different values and it is enough code to not want to duplicate. Let's refactor into standalone functions so it can be reused. Differential Revision: https://phab.mercurial-scm.org/D6318

automation: add --version argument to build-all-windows-packages This lets us pass a version string through when building all Windows packages, just like we can do with the individual commands which produce installers. Differential Revision: https://phab.mercurial-scm.org/D6317

automation: do a force push to synchronize We don't know what the state of the remote is. Force pushing will be more resilient. Differential Revision: https://phab.mercurial-scm.org/D6316

automation: add check that hg source directory is a repo Synchronizing from e.g. source distributions is not yet supported. Let's add a check so we fail with an error message indicating such. Differential Revision: https://phab.mercurial-scm.org/D6315

automation: shore up rebooting behavior There was a race condition in the old code. Use instance.stop()/instance.start() to eliminate it. As part of debugging this, I also found another race condition related to PowerShell permissions after the reboot. Unfortunately, I'm not sure the best way to work around it. I've added a comment for now. Differential Revision: https://phab.mercurial-scm.org/D6288

automation: wait longer for WinRM connection I got a few timeouts waiting for only 120s for the WinRM connection to become available. Increasing to 180s seems to fix. I guess AWS isn't as consistent as I would like :( Differential Revision: https://phab.mercurial-scm.org/D6287

automation: wait for instance profiles and roles Otherwise there is a race condition between creating the resources and us attempting to use them / them becoming available. The role waiter API was recently introduced, so we had to upgrade the boto3 package to get it. Other packages were also updated to latest versions just because. Even with this change, I still run into issues with the IAM instance profile not being available when we attempt to create an EC2 instance using a just-created profile. I'm not sure what's going on. Possibly a bug on Amazon's end. But the new behavior is "more correct." Differential Revision: https://phab.mercurial-scm.org/D6286

automation: don't create resources when deleting things Otherwise running these commands can result in resources being created. In the case of `purge-ec2-resources`, we will create resources only to delete them immediately afterwards! With this change, `purge-ec2-resources` now no-ops if no resources exist. # no-check-commit because foo_bar function name Differential Revision: https://phab.mercurial-scm.org/D6285

automation: detach policies before deleting role You can't delete an IAM role that has attached policies. With this change, the purge-ec2-resources command now works. Differential Revision: https://phab.mercurial-scm.org/D6284

automation: only iterate over our AMIs We can't delete AMIs that we don't own. Iterating over other AMIs won't work and slows down execution. Differential Revision: https://phab.mercurial-scm.org/D6283

remotefilelog: move most setup from onetimesetup() to uisetup() All the wrappers moved in this patch check if remotefilelog is enabled before they change behavior, so it's safe to always wrap. Differential Revision: https://phab.mercurial-scm.org/D6334

remotefilelog: move most functions in onetimeclientsetup() to top level This is how most extensions seem to do it. It makes sure we don't accidentally depend on the captured ui instance. Differential Revision: https://phab.mercurial-scm.org/D6333

tests: avoid the word "dirty" to mean "not a descendant of merge base" The term "dirty" is no longer used in the code since 57203e0210f8 (copies: calculate mergecopies() based on pathcopies(), 2019-04-11). Differential Revision: https://phab.mercurial-scm.org/D6373

releasenotes: add a file in which to record release notes I've just spent a few very boring hours going through the changelog for the 5.0 release (829 commits). We only had 5 commits that used the syntax that the release notes extension expects. This commit adds a file in which we can record important changes. The file should preferably be edited in the patch that makes the important change, but it can also be edited after (I think this is an important benefit compared to the release notes extension). I'm thinking that we can rename the file from "next" to "5.1" or something when it's time, and then we'd create a new "next" file on the default branch. I've used the syntax that we use on the our wiki in the template, but I don't care much that we use any valid syntax at all. The idea is mostly to record important changes when they happen. I expect that some copy editing will be needed at release time anyway. Differential Revision: https://phab.mercurial-scm.org/D6332

record: avoid modifying the matcher passed as a method parameter No problem observed, but I remember the previous pattern causing problems with largefiles and/or subrepos. This special matcher was added in 419ac63fe29c, so directly modifying the `fail` callback was probably an oversight in 44611ad4fbd9. Differential Revision: https://phab.mercurial-scm.org/D6371

sslutil: add support for SSLKEYLOGFILE to wrapsocket I recently learned of a Firefox/Chrome feature that allows wiresharking otherwise-TLS'd network connections. Gloriously, there's a pypi module that enables this same feature on Python, so let's add support for it to Mercurial in case we need to wireshark some HTTPs connections. Differential Revision: https://phab.mercurial-scm.org/D6343

phabricator: add custom vcr matcher to match request bodies Currently when the phabricator extension's conduit output changes the tests don't notice since the default vcr matcher only matches on 'method' and 'uri', not the body. Add a custom matcher that checks the same params are in the body (ignoring ordering). vcr's in-built body matcher can't be used since it fails under py3 with a "UnicodeEncodeError" on the "€ in commit message" tests. The DREV ids have decreased since the recordings were generated against a different phabricator instance to avoid spamming mercurial-devel. Differential Revision: https://phab.mercurial-scm.org/D6347

merge with stable

absorb: be more specific when erroring out on merge commit When you have a merge commit checked out and run `hg absorb`, it would tell you abort: no mutable changeset to change That makes it sound like the problem is public commits when isn't really. Let's be more specific in this case. There was already a test case that test this, so that now prints the new message. I added a new test case that shows the old message (when a public commit is checked out). Differential Revision: https://phab.mercurial-scm.org/D6354

remotefilelog: log when we're about to fetch files I'm debugging a slow client situation and knowing how many files are in the batch request would be a nice thing. Differential Revision: https://phab.mercurial-scm.org/D6353

revset: populate wdir() by its hash or revision number It belongs to the same category as the null hash/revision, and we do handle these virtual identifiers in id()/rev() predicates. Let's do that more consistently.

revset: extract private constant of {nullrev, wdirrev} set I'll add a few more users of this constant to get around wdir identifiers.

help: suggest merge() revset instead of -m/--only-merges Suggested by Dr Rainer Woitok.

tests: update annotate tests to work around simplemerge bug test-annotate.t and test-fastannotate.hg were failing with --pure since 57203e0210f8 (copies: calculate mergecopies() based on pathcopies(), 2019-04-11). It turned out to be because the pure file merge code behaved differently. I'm guessing it's the mdiff.get_matching_blocks() that behaves differently, but I haven't confirmed that. With this content in the base: a a a And this on the local side: a z a And this on the other side: a a a b4 c b6 It produced this conflict: a z a <<<<<<< working copy: b80e3e32f75a - test: c ||||||| base a ======= a b4 c b5 >>>>>>> merge rev: 64afcdf8e29e - test: mergeb I don't care enough about the pure Python code to fix it, so this patch just updates the tests to manually resolve the conflict. Differential Revision: https://phab.mercurial-scm.org/D6351

copies: delete misplaced comment The comment was added in 78d760aa3607 (duplicatecopies: do not mark items not in the dirstate as copies, 2013-03-28). It became misplaced in 3666331164bb (cmdutil: add copy-filtering support to duplicatecopies, 2014-06-07). Then the relevant code was moved far away in 754b5117622f (context: add workingfilectx.markcopied, 2017-10-15). Differential Revision: https://phab.mercurial-scm.org/D6352

phabricator: include branch in the phabread output Depends on D6301 Differential Revision: https://phab.mercurial-scm.org/D6302

phabricator: fallback to reading metadata from diff for phabread Differential Revision: https://phab.mercurial-scm.org/D6301

phabricator: include commit (node) and parent in the local:commits metadata Differential Revision: https://phab.mercurial-scm.org/D6298

copies: remove redundant filtering of ping-pong renames in _chain() We already handle the ping-pong rename case in the filtering step, so there's very little point in doing it in the chaining loop (ping-pong renames are very rare, so I'm not worried about the cost of adding it and then removing it again). Differential Revision: https://phab.mercurial-scm.org/D6344

repair: reword comments that I noticed while working on source formatting I think this is clearer, and one will also keep us from upsetting check-code when other formatting cleanups happen. Differential Revision: https://phab.mercurial-scm.org/D6339

gendoc: nest command headers under category headers Differential Revision: https://phab.mercurial-scm.org/D6329