rust-dirstate: create dirstate submodule This change is here to facilitate a future patch that is written in a different file. I expect this module to grow a few different files. Differential Revision: https://phab.mercurial-scm.org/D6389

profiling: show actual time spent in hotpath display To get, for instance: ... \ 6.6% 4.08s lock.py: __exit__ line 1566: ... | 6.5% 4.01s exchange.py: close line 1191: ... | 6.5% 4.01s transaction.py: _active line 1443: ... | 6.5% 4.01s transaction.py: close line 47: ... | 6.2% 3.84s scmutil.py: wrapped line 529: ... | 6.2% 3.81s localrepo.py: wrapper line 2114: ... | 6.2% 3.81s localrepo.py: updatecaches line 177: ... ... instead of: ... \ 6.6% lock.py: __exit__ line 1566: ... | 6.5% exchange.py: close line 1191: ... | 6.5% transaction.py: _active line 1443: ... | 6.5% transaction.py: close line 47: ... | 6.2% scmutil.py: wrapped line 529: ... | 6.2% localrepo.py: wrapper line 2114: ... | 6.2% localrepo.py: updatecaches line 177: ... ... I find that if it's not displayed, I frequently end up estimating the numbers by hand. Differential Revision: https://phab.mercurial-scm.org/D6477

merge with stable

merge with stable

root: add template variables pointing to repository directories These paths are useful for GUI applications to detect changes. A GUI process typically monitors .hg and .hg/store directories so that it will be notified on lock/wlock deletion. Alternatively, maybe we can add debugpaths command if we don't want to extend the root command. I'm not sure which will be nicer.

root: add support for -Tformatter option It's useless right now, but it should just work and I want to add a few more fields.

narrow: pass the bundle to bundle2.widen_bundle() instead of generating there This will make the code in narrowwirepeer.py more better for further refactoring. Differential Revision: https://phab.mercurial-scm.org/D6438

narrow: refactor code around widening complicated by previous patch Previous patch while adding support for using narrow_widen wireproto command, complicated the code a bit. This patch refactors that. Differential Revision: https://phab.mercurial-scm.org/D6437

narrow: use narrow_widen wireproto command to widen in case of ellipses Few releases ago, we introduce narrow_widen wireproto command to be used to widen narrow repositories. Before this patch, that was used in non-ellipses cases only. In ellipses cases, we still do exchange.pull() which can pull more data than required. After this patch, the client will first check whether server supports doing ellipses widening using wireproto command or not by checking server's wireproto capability. If the server is upto date and support latest ellipses capability, we call the wireproto command. Otherwise we fallback to exchange.pull() like before. The compat code make sure that things works even if one of the client or server is old. The initial version of this patch does not had this compat code. It's added to help Google release things smoothly internally. I plan to drop the compat code before the upcoming major release. Due to change to wireproto command, the code looks a bit dirty, next patches will clean that up. Differential Revision: https://phab.mercurial-scm.org/D6436

merge: correct argument name in docstring Differential Revision: https://phab.mercurial-scm.org/D6476

narrowspec: replace one recursion-avoidance hack with another When updating the working copy narrowspec, we call context.walk() in order to find which files to update the working copy with. context.walk() calls repo.narrowmatch(). In order to avoid infinite recursion in this case, we have a hack that assigns the new values for repo.narrowpats and repo._narrowmatch. However, doing that of course breaks future invalidation of those properties (they're @storecache'd). Let's instead avoid the infinite recursion by setting a flag on the repo instance when we're updating the working copy. Differential Revision: https://phab.mercurial-scm.org/D6468

merge: simplify initialization of "pas" Differential Revision: https://phab.mercurial-scm.org/D6472

merge: reorder some initialization to make more sense This puts the closely related definitions of "pl", "p1", "p2", "pas" close together, and moves the definition of "overwrite" away and closer to where it's first used. Differential Revision: https://phab.mercurial-scm.org/D6471

rust-dirstate: architecture independence fix Apparently, c_char is u8 on ppc64le and i8 on amd64 Differential Revision: https://phab.mercurial-scm.org/D6473

context: get filesadded() and filesremoved() from changeset if configured This adds the read side for getting the sets of added and removed files from the changeset extras. I timed this command on the hg repo: hg log -T '{rev}\n {files}\n %:{file_mods}\n +{file_adds}\n -{file_dels}\n' It took 1m21s before and 6.4s after. I also used that command to check that the result didn't change compared to calculating the values from the manifests on the fly (it didn't change). In the mozilla-unified repo, the same command run on FIREFOX_BETA_58_END::FIREFOX_BETA_59_END went from 29s to 0.67s. Differential Revision: https://phab.mercurial-scm.org/D6417

changelog: optionally store added and removed files in changeset extras As mentioned in an earlier patch, copies._chain() is used a lot in the changeset-centric version of pathcopies(). It is expensive because it needs to look at the manifest in order to filter out copies whose target file has since been removed. I want to store the sets of added and removed files in the changeset in order to speed that up. This patch does the writing part of that. It could easily be a separate config, but it's currently tied to experimental.copies.write-to since that's the only real use case (it will also make the {file_*} template keywords faster, but I doubt that anyone cares enough about those to write extra metadata for them). The new information is stored in the changeset extras. Since they're always subsets of the changeset's "files" list, they're stored as indexes into that list. I've stored the indexes as stringified ints separated by NUL bytes. The size of 00changelog.d for the hg repo increased in size by 0.28% percent (compared to the size with only copy information in the changesets, which in turn is 0.17% larger than without copy information). We could store only the delta between the indexes and we could store them in binary, but the chosen format is more readable. We could also have implemented this as a cache outside the changelog. One advantage of doing it that way is that we would get the speedups from the {file_*} template keywords also on old repos. Another advantage is that it we can rewrite the cache if we find a bug in how we calculate the set of files. A disadvantage is that it would be more complex. Another is that it would surely use more space. We already write the copy information to the changeset extras, so it seems like a small step to also write these file sets. Differential Revision: https://phab.mercurial-scm.org/D6416

templatekw: make {file_*} compare to both merge parents (issue4292) This redefines the {file_adds}, {file_dels}, {file_mods} template keywords by getting the lists from the recently introduced context methods instead of getting them from status compared to p1. As mentioned before, these are better defined on merge commits. The total number of files from the three lists now always add up to the number of files in {files}. I timed this command: hg log -r 4.0::5.0 -T '{rev}\n {file_mods}\n {file_adds}\n {file_dels}\n' It went from 7.6s to 5.6s with this patch. So it's actually faster than before. Note that the "files:" field in the bazaar test log output was using "{file_mods}" (not "{files}" as one might think based on the label). Differential Revision: https://phab.mercurial-scm.org/D6369

narrowspec: use vfs.tryread() instead of reimplementing Note that parseconfig() works well with empty strings. Differential Revision: https://phab.mercurial-scm.org/D6465

help: remove a superfluous "the" in revlogs text Differential Revision: https://phab.mercurial-scm.org/D6466

setdiscovery: make progress on most connected groups each roundtrip Consider history like this: o | o | | | o | | | o |/ o | o | | | o | | | o |/ o | o | | | o | | | o |/ o ~ Assume the left mainline is available in the remote repo and the other commits are only in the local repo. Also imagine that instead of 3 local branches with 3 commits on each, there are 1000 branches (the number of commits on each doesn't matter much here). In such a scenario, the current setdiscovery code will pick a sample size of 200 among these branches and ask the remote which of them it has. However, the discovery for each such branch is completely independent of the discovery for the others -- knowing whether the remote has a commit in one branch doesn't give us any information about the other branches. The discovery will therefore take at least 5 roundtrips (maybe more depending on which commit in each linear chain was sampled). Since the discovery for each branch is independent, there is no reason to let one branch wait for another, so this patch makes it so we sample at least as many commits as there are branches. It may still happen (it's very likely, even) that we get multiple samples from one branch and none from another, but that will even out over a few rounds and I think this is still a big improvement. Because of http header size limits, we still use the old behavior unless experimental.httppostargs=true. I've timed this by running `hg debugdiscovery mozilla-unified --debug` in the mozilla-try repo. Both repos were local. Before this patch, last part of the output was: 2249 total queries in 5276.4859s elapsed time: 5276.652634 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 After this patch, the output was (including all the samples, since there were so few now): taking initial sample query 2; still undecided: 1599476, sample size is: 108195 sampling from both directions query 3; still undecided: 810922, sample size is: 194158 sampling from both directions query 4; still undecided: 325882, sample size is: 137302 sampling from both directions query 5; still undecided: 111459, sample size is: 74586 sampling from both directions query 6; still undecided: 26805, sample size is: 23960 sampling from both directions query 7; still undecided: 2549, sample size is: 2528 sampling from both directions query 8; still undecided: 21, sample size is: 21 8 total queries in 24.5064s elapsed time: 24.670051 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 Differential Revision: https://phab.mercurial-scm.org/D2647

help: clarify overlap of revlog header and first revlog entry Differential Revision: https://phab.mercurial-scm.org/D6449

py3: fix test-convert-svn-sink.t In cases where the root commit is empty commit, None will be returned as parents. This was implemented by 2c13e91ede6e. This breaks test on py3 because `b'%s' % None` does not work. It does not matter whether we return `None` or `'None'` as we skipped converting to svn step by doing an early return. So let's return `'None'`. I tried to patch all the users to convert `None` to `'None'`, but there were more users than I expected. I hit 3 of them and decided to fix it this way around. Differential Revision: https://phab.mercurial-scm.org/D6458

commit: respect --no-edit in combination with --amend Differential Revision: https://phab.mercurial-scm.org/D6464

commit: add test showing that commit --amend --no-edit still shows editor Differential Revision: https://phab.mercurial-scm.org/D6463

githelp: translate git stash show and clear actions and --patch flag Differential Revision: https://phab.mercurial-scm.org/D6461

githelp: add --dry-run for mv Differential Revision: https://phab.mercurial-scm.org/D6460

githelp: translate --directory of git apply to --prefix According to the help pages, these flags do the same. Differential Revision: https://phab.mercurial-scm.org/D6459

help: include subtopic in error message if passed Differential Revision: https://phab.mercurial-scm.org/D6442

help: check if a subtopic exists and raise an error if it doesn't (issue6145) Differential Revision: https://phab.mercurial-scm.org/D6441

perf: fix some missing b prefixes # skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D6457

testparseutil: fix doctest to use str instead of bytes Differential Revision: https://phab.mercurial-scm.org/D6456

testparseutil: stop extracting using std* streams as bytes on py3 This is no longer required due to other cleanups in our linting tools. Differential Revision: https://phab.mercurial-scm.org/D6455

tests: sort some imports that were previously missed I'm a little unclear why the import checker didn't catch this before, but when I fixed it to work in Python 3 this failure started showing up. Sigh. Differential Revision: https://phab.mercurial-scm.org/D6454

contrib: fix import-checker to operate on str instead of bytes I believe this is fallout from other Python 3 cleanups, and our code linting tools are now leaning towards operating on str and not bytes. I don't feel strongly, so I've just restored this tool to working on Python 3. Differential Revision: https://phab.mercurial-scm.org/D6453

verify: use self._err not self.err, it changed in 7eaf4b1ac2a3 Differential Revision: https://phab.mercurial-scm.org/D6451

tests: make run-tests exit non-zero if there are "errors" Previously, if there was an error such as a broken .t file that caused run-tests.py to encounter an exception during parsing, the test would be considered in an "errored" state, which is separate from "failed". The check for whether to exit non-zero or not was based entirely on whether there were any tests in a "failed" state, so if there was only an error, run-tests would exit with 0. Our test infrastructure would then consider the test as passing, causing us to have some tests with false negatives that have gone undetected for a few weeks now. Differential Revision: https://phab.mercurial-scm.org/D6452

perf: add a `perfhelper-mergecopies` command This command gather data that are useful to pick argument for `perfmergecopies`.

perf: add a new `perfmergecopies` command This command benchmark calls to `mercurial.copies.mergecopies`

perf: factor selection of revisions involved in the merge out We will introduce more performance command around merge. As a first step we factor out pieces of `perfmergecalculate` that can be reused.

perf: allow to specify the base of the merge in perfmergecalculate We can now test the rebase case.

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