Wed, 24 Jul 2019 16:19:00 -0700 fix: ignore fixer tool configurations that are missing patterns
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:19:00 -0700] rev 42655
fix: ignore fixer tool configurations that are missing patterns This is to prevent a crash under the same circumstances. This is also to avoid data loss due to accidental application of a fixer tool to all files, if the matching logic somehow changed to that effect. Affecting all files until otherwise configured would be dangerous, and not very useful. We shouldn't abort because there may be other fixers, and it may still be useful to run them without having to adjust configuration. A user might not feel confident in changing configs, for example. Differential Revision: https://phab.mercurial-scm.org/D6693
Wed, 24 Jul 2019 16:21:12 -0700 fix: add a test case around the effect of cwd on pattern matching
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:21:12 -0700] rev 42654
fix: add a test case around the effect of cwd on pattern matching This was not covered by previous tests. It is related to a regression encountered at Google due to misconfiguration of [fix]. Differential Revision: https://phab.mercurial-scm.org/D6692
Wed, 24 Jul 2019 16:22:45 -0700 fix: remove support for :fileset sub-config in favor of :pattern
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:22:45 -0700] rev 42653
fix: remove support for :fileset sub-config in favor of :pattern Differential Revision: https://phab.mercurial-scm.org/D6691
Tue, 23 Jul 2019 15:01:28 -0400 fsmonitor: add support for extra `hg debuginstall` data
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 15:01:28 -0400] rev 42652
fsmonitor: add support for extra `hg debuginstall` data This might make some things easier to debug, and for default bug report templates it'll help collect more data from users all at once. I don't actually need fsmonitor in our bug reports (we don't use it), but this demonstrates the utility of the preceding patches without having to add new things to core. Differential Revision: https://phab.mercurial-scm.org/D6682
Tue, 23 Jul 2019 14:37:51 -0400 debugcommands: add support for extensions adding their own debug info
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:37:51 -0400] rev 42651
debugcommands: add support for extensions adding their own debug info We've had a couple of cases where it'd be handy at Google to add data to `hg debuginstall`'s output. We've kludged around that at various times, but it seems reasonable to let extensions add their own data here so extension maintainers can get useful extra data. Differential Revision: https://phab.mercurial-scm.org/D6681
Tue, 23 Jul 2019 14:36:38 -0400 fsmonitor: refactor watchmanclient.client to accept ui and repo path
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:36:38 -0400] rev 42650
fsmonitor: refactor watchmanclient.client to accept ui and repo path This will make my next patch simpler. Differential Revision: https://phab.mercurial-scm.org/D6680
Mon, 22 Jul 2019 19:10:59 -0700 contrib: install Python 3.8b2 instead of 3.8a2 stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:10:59 -0700] rev 42649
contrib: install Python 3.8b2 instead of 3.8a2 Let's install the most recent Python 3.8 distribution. Differential Revision: https://phab.mercurial-scm.org/D6674
Mon, 22 Jul 2019 19:06:20 -0700 automation: make Windows base image name configurable stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:06:20 -0700] rev 42648
automation: make Windows base image name configurable Since automation broke in the middle of the 5.0 release cycle, there's a good chance it will break again in the future. While a robust solution might be to search for all available images and choose the newest one, it does seem useful to be able to explicitly choose the name of the image to find and use so users can opt in to using a different image. This commit implements that functionality. Differential Revision: https://phab.mercurial-scm.org/D6673
Mon, 22 Jul 2019 18:55:52 -0700 automation: extract strings to constants stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:55:52 -0700] rev 42647
automation: extract strings to constants Differential Revision: https://phab.mercurial-scm.org/D6672
Mon, 22 Jul 2019 18:52:58 -0700 automation: use newer Windows base image stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:52:58 -0700] rev 42646
automation: use newer Windows base image It looks like the old base image disappeared. Let's use a newer image that exists today. Differential Revision: https://phab.mercurial-scm.org/D6671
Mon, 22 Jul 2019 17:44:19 -0700 copies: fix crash on in changeset-centric tracing from commit to itself stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 17:44:19 -0700] rev 42645
copies: fix crash on in changeset-centric tracing from commit to itself When we trace copies from a changeset to itself, the "work" queue ends up empty and we hit the "assert False" after it. It was only the last of the three added tests that failed before this patch. That is because the other two cases have fast paths, so _committedforwardcopies() is never reached. Differential Revision: https://phab.mercurial-scm.org/D6675
Tue, 23 Jul 2019 12:03:24 +0530 unshelve: add help text on --interactive in verbose mode stable
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 23 Jul 2019 12:03:24 +0530] rev 42644
unshelve: add help text on --interactive in verbose mode This is a follow-up patch to rHG9eace8d6d537. This modifies the help text of unshelve in verbose mode to mention the details about `--interactive` flag. Differential Revision: https://phab.mercurial-scm.org/D6676
Mon, 22 Jul 2019 06:33:11 -0400 amend: stop committing unrequested file reverts (issue6157) stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:11 -0400] rev 42643
amend: stop committing unrequested file reverts (issue6157) Differential Revision: https://phab.mercurial-scm.org/D6667
Mon, 22 Jul 2019 06:33:00 -0400 amend: add a test for a simplified version of issue6157 stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:00 -0400] rev 42642
amend: add a test for a simplified version of issue6157 Differential Revision: https://phab.mercurial-scm.org/D6666
Sun, 21 Jul 2019 18:04:05 -0700 py: error out if a "skip" character was given with non-dict to util.dirs() stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 18:04:05 -0700] rev 42641
py: error out if a "skip" character was given with non-dict to util.dirs() util.dirs() keeps track of the directories in its input collection. If a "skip" character is given to it, it will assume the input is a dirstate map and it will skip entries that are in the given "skip" state. I think this is used only for skipping removed entries ("r") in the dirtate. The C implementation of util.dirs() errors out if it was given a skip character and a non-dict was passed. The pure implementation simply ignored the request skip state. Let's make it easier to discover bugs here by erroring out in the pure implementation too. Let's also switch to checking for the dict-ness, to make the C implementation (since that's clearly been sufficient for many years). This last change makes test-issue660.t pass on py3 in pure mode, since the old check was for existence of iteritems(), which doesn't exist on py3. Differential Revision: https://phab.mercurial-scm.org/D6669
Mon, 22 Jul 2019 09:55:05 -0700 py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 09:55:05 -0700] rev 42640
py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc Both places should have been changed from 185 to 187. Differential Revision: https://phab.mercurial-scm.org/D6668
Mon, 22 Jul 2019 14:08:56 -0400 Added signature for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:56 -0400] rev 42639
Added signature for changeset e386b5f4f836
Mon, 22 Jul 2019 14:08:54 -0400 Added tag 5.1rc0 for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:54 -0400] rev 42638
Added tag 5.1rc0 for changeset e386b5f4f836
Mon, 22 Jul 2019 14:00:33 -0400 merge default into stable for 5.1 release stable 5.1rc0
Augie Fackler <augie@google.com> [Mon, 22 Jul 2019 14:00:33 -0400] rev 42637
merge default into stable for 5.1 release
Sun, 21 Jul 2019 14:42:01 +0900 rust-filepatterns: unescape comment character property
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 14:42:01 +0900] rev 42636
rust-filepatterns: unescape comment character property There were multiple issues in the original implementation: a. the local variable "line" dropped soon after replace_slice() applied b. replace_slice() was noop since br"\#".len() != b"#" This patch uses bytes::Regex::replace_all() since it seems the simplest way to replace bytes of arbitrary length, and I don't think we have to avoid using Regexp here.
Sun, 21 Jul 2019 13:00:54 +0900 rust-filepatterns: use literal b'#' instead of cast
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:00:54 +0900] rev 42635
rust-filepatterns: use literal b'#' instead of cast
Sun, 21 Jul 2019 12:46:57 +0900 rust-filepatterns: fix type of warnings tuple to (bytes, bytes)
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 12:46:57 +0900] rev 42634
rust-filepatterns: fix type of warnings tuple to (bytes, bytes) Otherwise warn() in match.py would fail if the warning contains non-ASCII character. We might want to add a thin ByteString wrapper around Vec<u8> to implement ToPyObject<ObjectType = PyBytes>, but I'm not sure.
Sun, 21 Jul 2019 13:48:29 +0900 hgignore: add escape syntax test for glob patterns
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:48:29 +0900] rev 42633
hgignore: add escape syntax test for glob patterns The last example, [\#], is what the rust implementation fails to parse. The other escapes can be removed by regexp engine or _globre().
Sun, 21 Jul 2019 13:37:24 +0900 hgignore: add a few more weird patterns to test case
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:37:24 +0900] rev 42632
hgignore: add a few more weird patterns to test case
Sun, 21 Jul 2019 13:30:47 +0900 hgignore: update \-escape test to reflect actual behavior
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:30:47 +0900] rev 42631
hgignore: update \-escape test to reflect actual behavior "\\<char>" is not an escape character but "\\" + <char>.
Sat, 20 Jul 2019 11:04:49 -0700 py3: add a b'' prefix in tests/test-convert-identity.t
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 Jul 2019 11:04:49 -0700] rev 42630
py3: add a b'' prefix in tests/test-convert-identity.t Differential Revision: https://phab.mercurial-scm.org/D6662
Fri, 19 Jul 2019 09:43:50 -0700 lookup: don't use "00changelog.i@None" when lookup of prefix fails
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Jul 2019 09:43:50 -0700] rev 42629
lookup: don't use "00changelog.i@None" when lookup of prefix fails We were shadowing the "node" variable, so we always passed None to the LookupError instead of the node we meant to pass. (This showed up in py3 tests since py3 doesn't like to format None using "%s".) Differential Revision: https://phab.mercurial-scm.org/D6661
Thu, 18 Jul 2019 14:23:21 -0400 py3: fix test-setdiscovery.t on Python 3 by conditionalizing two lines
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:23:21 -0400] rev 42628
py3: fix test-setdiscovery.t on Python 3 by conditionalizing two lines I'm not clear why this behaves very slightly differently on Python 3, but I'm also not concerned about it. Differential Revision: https://phab.mercurial-scm.org/D6658
Fri, 19 Jul 2019 01:49:10 +0530 commands: removed part of description from abort and continue
Taapas Agrawal <taapas2897@gmail.com> [Fri, 19 Jul 2019 01:49:10 +0530] rev 42627
commands: removed part of description from abort and continue The description for registration of new `continuefunc` or `abortfunc` is removed as it is not required from user perspective. Differential Revision: https://phab.mercurial-scm.org/D6660
Sat, 20 Jul 2019 22:18:22 -0400 tests: glob over some timing numbers in test-shelve.t
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Jul 2019 22:18:22 -0400] rev 42626
tests: glob over some timing numbers in test-shelve.t The Windows bot is slow enough that it was 2s in the first hunk. Differential Revision: https://phab.mercurial-scm.org/D6663
Thu, 18 Jul 2019 14:18:20 -0400 py3: another passing test
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:18:20 -0400] rev 42625
py3: another passing test Differential Revision: https://phab.mercurial-scm.org/D6656
Thu, 18 Jul 2019 14:19:41 -0400 cleanup: remove redundant import
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:19:41 -0400] rev 42624
cleanup: remove redundant import For some reason the import checker only caught this on py3. Differential Revision: https://phab.mercurial-scm.org/D6657
Thu, 18 Jul 2019 21:10:17 +0530 shelve: modify help text on --interactive
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 21:10:17 +0530] rev 42623
shelve: modify help text on --interactive We now have `unshelve --interactive` after rHG5162753c4c14. So, the help text on `shelve --interactive` suggesting that it only works for `shelve` can be removed. Differential Revision: https://phab.mercurial-scm.org/D6654
Thu, 18 Jul 2019 20:54:26 +0530 unshelve: mark unshelve interactive as experimental
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 20:54:26 +0530] rev 42622
unshelve: mark unshelve interactive as experimental This is a follow-up patch to rHG5162753c4c14. We have the logic for interactive unshelve under `_rebaserestorecommit()`. So, we might get conflicts even if there are conflicting changes other than selected changes by the user. We should mark unshelve `--interactive` as `EXPERIMENTAL` until we solve this issue. Differential Revision: https://phab.mercurial-scm.org/D6653
Tue, 02 Jul 2019 12:59:58 -0400 commit: improve the files field of changelog for merges
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:59:58 -0400] rev 42621
commit: improve the files field of changelog for merges Currently, the files list of merge commits repeats all the deletions (either actual deletions, or files that got renamed) that happened between base and p2 of the merge. If p2 is the main branch, the list can easily be much bigger than the change being merged. This results in various problems worth improving: - changelog is bigger than necessary - `hg log directory` lists many unrelated merge commits, and `hg log -v -r commit` frequently fills multiple screens worth of files - it possibly slows down adjustlinkrev, by forcing it to read more manifests, and that function can certainly be a bottleneck - the server side of pulls can waste a lot of time simply opening the filelogs for pointless files (the constant factors for opening even a tiny filelog is apparently pretty bad) So stop listing such files as described in the code. Impacted merge commits and their descendants get a different hash than they would have without this. This doesn't seem problematic, except for convert. The previous commit helped with that in the hg->hg case (but if you do svn->hg twice from scratch, hashes can still change). The rest of the description is numbers. I don't have much to report, because recreating the files list of existing repositories is not easy: - debugupgradeformat and bundle/unbundle don't recreate the list - export/import tends to choke quickly applying patches or on description that contain diffs, - merge commits from the convert extension don't have the right files list for reasons orthogonal to the current commit - replaying the merge with hg update/hg merge/hg revert --all/hg commit can end up failing in hg revert - I wasn't sure that using debugsetparents + debugrebuilddirstate would really build the right thing I measured commit time before and after this change, in a case with no files filtered out, several files filtered out (no difference) and 5k files filtered out (+1% time). Recreating the 100 more recent merges in a private repo, the concatenated uncompressed files lists goes from 1.12MB to 0.52MB. Excluding 3 merges that are not representative, then the size goes from 570k to 15k. I converted part of mozilla-central, and observed file list shrinking quite a bit too, starting at the very first merge, 733641d9feaf, going from 550 files to 10 files (although they have relatively few merges, so they probably wouldn't care). Differential Revision: https://phab.mercurial-scm.org/D6613
Sat, 13 Jul 2019 23:45:32 -0400 convert: add a config option to help doing identity hg->hg conversion
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 13 Jul 2019 23:45:32 -0400] rev 42620
convert: add a config option to help doing identity hg->hg conversion I want to change the computation of the list of files modified by a commit. In principle, this would simply change a cache. But since this information is stored in commits rather than a cache, changing it means changing commit hashes (going forward). Some users rely on the convert extension from hg to hg not changing hashes when nothing changes (usually). Allow these users to preserve hashes despite changes to the changelog files computation by reusing these files lists when the manifest is unchanged (since these files list are derived from the manifest). Differential Revision: https://phab.mercurial-scm.org/D6643
Tue, 02 Jul 2019 12:55:51 -0400 tests: show the files fields of changelogs for many merges
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:55:51 -0400] rev 42619
tests: show the files fields of changelogs for many merges I don't think there's coverage for many of the subtle cases, and I found it hard to understand what the code is doing by reading it. The test takes 40s to run on a laptop, or 9s with --chg. I have yet to find a description of what the files field is supposed to be for merges. I thought it could be one of: 1. the files added/modified/removed relative to p1 (wouldn't seem useful, but `hg diff -c -r mergerev` has this behavior) 2. the files with filelog nodes not in either parent (i.e., what is needed to create a bundle out of a commit) 3. the files added/removed/modified files by merge itself [1] It's clearly not 1, because file contents merges are symmetric. It's clearly not 2 because removed files and exec bit changes are listed. It's also not 3 but I think it's intended to be 3 and the differences are bugs. Assuming 3, the test shows that, for merges, the list of files both overapproximates and underapproximates. All the cases involve file changes not in the filelog but in the manifest (existence of file at revision, exec bit and file vs symlink). I didn't look at all underapproximations, but they looked minor. The two overapproximations are problematic though because they both cause potentially long lists of files when merging cleanly. [1] even what it means for the merge commit itself to change a file is not completely trivial. A file in the merge being the same as in one of the parent is too lax as it would consider that merges change nothing when they revert all the changes done on one side. The criteria used in the test and in the next commit for "merge didn't touch a file" is: - the parents and the merge all have the same file - or, one parent didn't touch the file and the other parent contains the same file as the merge Differential Revision: https://phab.mercurial-scm.org/D6612
Tue, 16 Jul 2019 19:18:16 +0100 phabricator: handle local:commits time being string or int
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 19:18:16 +0100] rev 42618
phabricator: handle local:commits time being string or int When setting local:commits arcanist has different behaviour depending on whether the repo is git or hg. With hg it sets the time as a number, since it calls PHP's strtotime on the value, but with git it sets it as a string. Normally this wouldn't be an issue since phabread wouldn't be interacting with Phabricator Revisions for git repos, but Mozilla has a secondary workflow for git users that uses the git-cinnabar tool to interact with their hg repos. When a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central it makes use of Mozilla's fork of arcanist, which works with their local git version of m-c, and thus sets the local:commit time as a string, and then translates the commit hashes. Currently when encountering such DREVS phabread dies with "TypeError: %d format: a number is required, not str". phabsend also used to set it as a string but wouldn't have encountered the issue with its own DREVs since it would read hg:meta first. Differential Revision: https://phab.mercurial-scm.org/D6650
Tue, 16 Jul 2019 18:38:38 +0100 phabricator: demonstrate broken phabread on string local:commit times
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 18:38:38 +0100] rev 42617
phabricator: demonstrate broken phabread on string local:commit times Differential Revision: https://phab.mercurial-scm.org/D6649
Tue, 02 Jul 2019 18:02:12 +0530 unshelve: add interactive mode
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 02 Jul 2019 18:02:12 +0530] rev 42616
unshelve: add interactive mode Until now, there is no way to `unshelve` selected changes only from the stored shelve as given in issue6162. This patch makes `unshelve` perform with certain changes only by adding an interactive mode. Differential Revision: https://phab.mercurial-scm.org/D6596
Sun, 07 Jul 2019 10:54:41 -0400 blackbox: disable extremely verbose logging (issue6110)
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 07 Jul 2019 10:54:41 -0400] rev 42615
blackbox: disable extremely verbose logging (issue6110) This is maybe not the best way to go about fixing this, but anything is better than the status quo. Differential Revision: https://phab.mercurial-scm.org/D6611
Wed, 17 Jul 2019 22:24:17 +0530 continue: added support for unshelve
Taapas Agrawal <taapas2897@gmail.com> [Wed, 17 Jul 2019 22:24:17 +0530] rev 42614
continue: added support for unshelve This patch adds the support for `ushelve` in `hg continue` plan. `hgcontinueunshelve()` has been created for independent calls. In case an interrupted unshelve is resumed via hg continue the shelvedstate needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgcontinueunshelve()` is then registered as `continuefunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6652
Tue, 16 Jul 2019 01:59:28 +0530 continue: added support for rebase
Taapas Agrawal <taapas2897@gmail.com> [Tue, 16 Jul 2019 01:59:28 +0530] rev 42613
continue: added support for rebase This adds support of rebase to hg continue plan. An independent continue logic for rebase is created under continuerebase() function. For this a seperate rebaseruntime object is created under the function to handle an interrupted rebasestate. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6646
Mon, 15 Jul 2019 22:23:31 +0530 continue: added logic for hg continue
Taapas Agrawal <taapas2897@gmail.com> [Mon, 15 Jul 2019 22:23:31 +0530] rev 42612
continue: added logic for hg continue This is part of GSoC19 project `Implement abort and continue commands`. This patch is part of the continue plan. This adds the basic logic for hg continue. This command aborts an multistep operation like graft, histedit, rebase, transplant and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under statemod. This API is extended to support hg continue by adding a method to register the abort logic as a function (here continuefunc). Once the unfinished operation is determined the registered logic is used to resume the command in case it is interrupted. The benefit of this kind of framework is that any new extension developed can support hg continue by registering the command and logic under statedetection API. hg continue currently supports --dry-run/-n flag only. It is used to dry run hg abort Differential Revision: https://phab.mercurial-scm.org/D6645
Wed, 17 Jul 2019 18:15:51 +0200 rust-utils: remove buggy assertion
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Jul 2019 18:15:51 +0200] rev 42611
rust-utils: remove buggy assertion While this assertion had good intentions, it broke existing behavior with a nasty panic. Differential Revision: https://phab.mercurial-scm.org/D6651
Wed, 10 Jul 2019 17:41:07 +0200 rust-utils: add docstrings and doctests for utils.rs
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Jul 2019 17:41:07 +0200] rev 42610
rust-utils: add docstrings and doctests for utils.rs Differential Revision: https://phab.mercurial-scm.org/D6635
Tue, 02 Jul 2019 17:15:03 +0200 rust: switch hg-core and hg-cpython to rust 2018 edition
Raphaël Gomès <rgomes@octobus.net> [Tue, 02 Jul 2019 17:15:03 +0200] rev 42609
rust: switch hg-core and hg-cpython to rust 2018 edition Many interesting changes have happened in Rust since the Oxidation Plan was introduced, like the 2018 edition and procedural macros: - Opting in to the 2018 edition is a clear benefit in terms of future proofing, new (nice to have) syntactical sugar notwithstanding. It also has a new non-lexical, non-AST based borrow checker that has fewer bugs(!) and allows us to write correct code that in some cases would have been rejected by the old one. - Procedural macros allow us to use the PyO3 crate which maintainers have expressed the clear goal of compiling on stable, which would help in code maintainability compared to rust-cpython. In this patch are the following changes: - Removing most `extern crate` uses - Updating `use` clauses (`crate` keyword, nested `use`) - Removing `mod.rs` in favor of an aptly named module file Like discussed in the mailing list ( https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html ), until Rust integration in Mercurial is considered to be out of the experimental phase, the maximum version of Rust allowed is whatever the latest version Debian packages. Differential Revision: https://phab.mercurial-scm.org/D6597
Fri, 12 Jul 2019 11:08:31 +0200 rust-utils: use new find_dirs iterator
Raphaël Gomès <rgomes@octobus.net> [Fri, 12 Jul 2019 11:08:31 +0200] rev 42608
rust-utils: use new find_dirs iterator In cad3dde7a573, the `find_dirs` util was introduced, but the second changeset that made use of it didn't apply. This change fixes the issue. Differential Revision: https://phab.mercurial-scm.org/D6639
Tue, 16 Jul 2019 00:00:17 -0400 inno: correct the path display in a literal block of the readme
Matt Harbison <matt_harbison@yahoo.com> [Tue, 16 Jul 2019 00:00:17 -0400] rev 42607
inno: correct the path display in a literal block of the readme Otherwise, the path components allrantogether. Differential Revision: https://phab.mercurial-scm.org/D6648
Mon, 15 Jul 2019 15:29:22 -0700 copies: remove unnecessary override of p[12]copies() in workingctx
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Jul 2019 15:29:22 -0700] rev 42606
copies: remove unnecessary override of p[12]copies() in workingctx The implementation is identical to the version inherited from basectx. Differential Revision: https://phab.mercurial-scm.org/D6647
Fri, 12 Jul 2019 19:38:18 -0400 tests: properly position conditional output on Windows in test-subrepo.t
Matt Harbison <matt_harbison@yahoo.com> [Fri, 12 Jul 2019 19:38:18 -0400] rev 42605
tests: properly position conditional output on Windows in test-subrepo.t The test runner doesn't always guess the right location when optional output is missing. This goes with f6540aba8e3e. Differential Revision: https://phab.mercurial-scm.org/D6640
Thu, 11 Jul 2019 03:08:28 +0530 abort: removed labels argument from abortmerge()
Taapas Agrawal <taapas2897@gmail.com> [Thu, 11 Jul 2019 03:08:28 +0530] rev 42604
abort: removed labels argument from abortmerge() Labels are used to label the code that belongs to `working copy` and `merge rev` in case of a conflicted state. No such labelling is required while aborting merge as conflicted parts are reverted to normal. Differential Revision: https://phab.mercurial-scm.org/D6638
Fri, 12 Jul 2019 23:34:24 -0700 py3: source-transform only call-sites of iteritems(), not definitions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:34:24 -0700] rev 42603
py3: source-transform only call-sites of iteritems(), not definitions branchmap.branchcache, among other classes, defines a iteritems(). That currently gets replaced by items() by the source transformer. That makes it harder for extensions to work with both py2 and py3, since they have to call either items() or iteritems() on branchcache. Let's not replace definitions of iteritems() (and itervalues()) and only replace the call-sites. We need to also add an items() alias to branchcache (etc) so our transformer call-sites will find it. Differential Revision: https://phab.mercurial-scm.org/D6641
Sun, 14 Jul 2019 23:21:28 -0700 py3: fix formatting of branchmap log messages with repo.filtername=None
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Jul 2019 23:21:28 -0700] rev 42602
py3: fix formatting of branchmap log messages with repo.filtername=None `"%s" % None` does not work on py3. I've extracted a little function for producing a formatted message given the filter name. Differential Revision: https://phab.mercurial-scm.org/D6644
Sun, 14 Jul 2019 01:31:42 -0400 automation: correct the path separator in LIBPATH on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sun, 14 Jul 2019 01:31:42 -0400] rev 42601
automation: correct the path separator in LIBPATH on Windows I haven't tried building the x86 installer, but happened to notice this when working on the thg installer. Experimenting in PowerShell seems to show that LIBPATH was expanded at the end, but with ':' between, it effectively corrupted `${root}\WinSDK\Lib` and the first path in LIBPATH. Differential Revision: https://phab.mercurial-scm.org/D6642
Sun, 30 Jun 2019 01:07:14 +0530 abort: added support for merge
Taapas Agrawal <taapas2897@gmail.com> [Sun, 30 Jun 2019 01:07:14 +0530] rev 42600
abort: added support for merge This adds support of `hg merge --abort` to `hg abort` plan. This involves refactoring `hg.merge` into two different functions removing the abort logic of `merge` from `hg.merge` and then creating a seperate `hg.abortmerge` to handle the abort logic so that the abortion of merge can be called independently. `hg.abortmerge` is then registered as `abortfunc` for the state detection API so that `commands.abort` can use it to deal with an unfinished merge operation. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6588
Wed, 26 Jun 2019 22:15:07 +0530 abort: added support for unshelve
Taapas Agrawal <taapas2897@gmail.com> [Wed, 26 Jun 2019 22:15:07 +0530] rev 42599
abort: added support for unshelve This patch adds the support for shelve in `hg abort` plan. For this the logic to load a `shelvedstate` and the error handling for it had been shifted to a seperate function `_loadunshelvedstate()`. This returns a tuple with `state` file and `opts.` `hgabortunshelve()` has been created for independent calls. In case abortion of `unshelve` is called via `hg abort` the `shelvedstate` needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgabortunshelve()` is then registered as `abortfunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6579
Wed, 10 Jul 2019 23:11:55 +0530 unshelve: changed Corruptedstate error msg from ui.warn to error.Abort
Taapas Agrawal <taapas2897@gmail.com> [Wed, 10 Jul 2019 23:11:55 +0530] rev 42598
unshelve: changed Corruptedstate error msg from ui.warn to error.Abort This changes the message type of Corruptedstate error in case of `hg unshelve --abort` to error.Abort from warning message. This is done so as to avoid the return statement after the warning. Differential Revision: https://phab.mercurial-scm.org/D6636
Thu, 20 Jun 2019 01:08:56 +0530 mq: fix for merge detection methods
Taapas Agrawal <taapas2897@gmail.com> [Thu, 20 Jun 2019 01:08:56 +0530] rev 42597
mq: fix for merge detection methods Differential Revision: https://phab.mercurial-scm.org/D6548
Tue, 09 Jul 2019 00:03:10 -0700 py3: store _origdoc as str
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 00:03:10 -0700] rev 42596
py3: store _origdoc as str Since __doc__ is str, it seems natural that _origdoc also is. Differential Revision: https://phab.mercurial-scm.org/D6623
Fri, 28 Jun 2019 12:59:21 -0700 copies: follow copies across merge base without source file (issue6163)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 12:59:21 -0700] rev 42595
copies: follow copies across merge base without source file (issue6163) As in the previous patch, consider these two histories: @ 4 'rename x to y' | o 3 'add x again' | o 2 'remove x' | | o 1 'modify x' |/ o 0 'add x' @ 4 'rename x to y' | o 3 'add x again' | | o 2 'modify x' | | | o 1 'add x' |/ o 0 'base' We trace copies from the 'modify x' commit to commit 4 by going via the merge base (commit 0). When tracing file 'y' (_tracefile()) in the first case, we immediately find the rename from 'x'. We check to see if 'x' exists in the merge base, which it does, so we consider it a valid copy. In the second case, 'x' does not exist in the merge base, so it's not considered a valid copy. As a workaround, this patch makes it so we also attempt the check in mergecopies's base commit (commit 1 in the second case). That feels pretty ugly to me, but I don't have any better ideas. Note that we actually also check not only that the filename matches, but also that the file's nodeid matches. I don't know why we do that, but it was like that already before I rewrote mergecopies(). That means that the rebase will still fail in cases like this (again, it already failed before my rewrite): @ 4 'rename x to y' | o 3 'add x again with content X2' | o 2 'remove x' | | o 1 'modify x to content X2' |/ o 1 'modify x to content X1' | o 0 'add x with content X0' Differential Revision: https://phab.mercurial-scm.org/D6604
Tue, 25 Jun 2019 14:25:03 -0700 copies: filter invalid copies only at end of pathcopies() (issue6163)
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 14:25:03 -0700] rev 42594
copies: filter invalid copies only at end of pathcopies() (issue6163) copies._filter() filters out copies whose source file does not exist in the start commit or whose target file does not exist in the end commit. We do that after chaining copies with dirstate copies or backward renames from another branch. We also do at the end of the changeset-centric copy tracing. The filtering means that we will remove copies to/from files that did not exist in some intermediate commit. That is inconsistent with what we do if a file has been deleted and then re-added (we allow updating across that). Copying the two first examples from issue6163: @ 4 'rename x to y' | o 3 'add x again' | o 2 'remove x' | | o 1 'modify x' |/ o 0 'add x' @ 4 'rename x to y' | o 3 'add x again' | | o 2 'modify x' | | | o 1 'add x' |/ o 0 'base' When doing `hg rebase -r 1 -d 4` in the first case, it succeeds, but `hg rebase -r 2 -d 4` in the second case does not. That's because we chain and filter via commit 0, which does not have file 'x' in the second case. IMO, that's clearly inconsistent. So this patch removes the filtering step so it only happens at the end. If a file was temporarily removed, whether via a merge base or not, it will now still be considered the same file. That fixes issue6163 for the changeset-centric case. Differential Revision: https://phab.mercurial-scm.org/D6603
Tue, 25 Jun 2019 13:46:55 -0700 copies: inline _chainandfilter() to prepare for next patch
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 13:46:55 -0700] rev 42593
copies: inline _chainandfilter() to prepare for next patch Differential Revision: https://phab.mercurial-scm.org/D6602
Tue, 25 Jun 2019 13:33:49 -0700 copies: remove most early returns from pathcopies() and _forwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 13:33:49 -0700] rev 42592
copies: remove most early returns from pathcopies() and _forwardcopies() I want to split up _chainandfilter() more so the call to _filter() consistently happens at the end of pathcopies(). This prepares for that change. Differential Revision: https://phab.mercurial-scm.org/D6601
Fri, 28 Jun 2019 09:01:45 -0700 copies: move short-circuiting of dirstate copies out of _forwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 09:01:45 -0700] rev 42591
copies: move short-circuiting of dirstate copies out of _forwardcopies() I'd like to move the filtering of copies we do after chaining to the end of all chaining (in a single place in pathcopies()). One problem that came up when trying that was that we allow things like `hg cp -f <file> <existing file>` so the user can later amend that in. Filtering at the end would mean that we remove those copies. That would break `hg st -C`. This patch therefore moves the short-circuiting of dirstate copies into pathcopies() so we can more easily handle the dirstate-only case differently. I initially thought this might change some behavior when the user does `hg status --rev 'wdir()' --rev .` during an uncommitted merge, since _backwardrenames() would reverse the copies in that case. However, I couldn't come up with a test case where it made a difference. Differential Revision: https://phab.mercurial-scm.org/D6600
Fri, 21 Jun 2019 16:59:29 -0700 tests: add more tests of copy tracing with removed and re-added files
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jun 2019 16:59:29 -0700] rev 42590
tests: add more tests of copy tracing with removed and re-added files We had a test where the destination of a copy was removed and then added back. This patch adds similar cases where the break in history instead happens to the source file. There are three versions of this: 1. The break happens before the rename. 2. The break happens on a branch parallel to the rename (where copy tracing is done via the merge base) 3. The source is added on each side of the merge base. The break in history is thus in the form of a deletion when going backwards to the merge base and the re-add happens on the other branch. I've also added calls to `hg graft` in these cases to show the breakage in issue 6163. Another factor in these cases is matching nodeid (checked in copies._tracefile()). I've made two copies each of the cases to show the impact of that. One of these is the same as a test in test-rename-merge1.t, so I also deleted that test from there. Some of these tests currently fail, where "fail" is based on my current thinking of how things should work. I had initially thought that we should be more strict about not tracing copies across commits where the file did not exist, but issue 6163 made me reconsider. The only test case here that behaved differently in 4.9 is the exact case reported in issue 6163. Differential Revision: https://phab.mercurial-scm.org/D6599
Mon, 01 Jul 2019 14:24:51 -0700 tests: split out tests for unrelated copy source/target into separate file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Jul 2019 14:24:51 -0700] rev 42589
tests: split out tests for unrelated copy source/target into separate file I've realized only recently how many cases there are where a file is treated differently if it's considered "related" to another file (not deleted and re-added). I'll add more tests for some of these cases soon. Differential Revision: https://phab.mercurial-scm.org/D6598
Mon, 24 Jun 2019 16:01:01 -0700 subrepos: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Mon, 24 Jun 2019 16:01:01 -0700] rev 42588
subrepos: make last line of prompts <40 english chars (issue6158) Differential Revision: https://phab.mercurial-scm.org/D6572
Mon, 24 Jun 2019 16:00:39 -0700 largefiles: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Mon, 24 Jun 2019 16:00:39 -0700] rev 42587
largefiles: make last line of prompts <40 english chars (issue6158) Differential Revision: https://phab.mercurial-scm.org/D6571
Sun, 30 Jun 2019 18:32:43 +0900 rust-dirstate: add helper to iterate ancestor paths
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Jun 2019 18:32:43 +0900] rev 42586
rust-dirstate: add helper to iterate ancestor paths This is modeled after std::path::Path::ancestors(). find_dirs(b"") yields b"" because Mercurial's util.finddirs() works in that way, and the test case for DirsMultiset expects such behavior.
Tue, 09 Jul 2019 20:51:48 -0400 tests: update test-commit-interactive.t for no-execbit platforms
Matt Harbison <matt_harbison@yahoo.com> [Tue, 09 Jul 2019 20:51:48 -0400] rev 42585
tests: update test-commit-interactive.t for no-execbit platforms These changes correspond with f802a75da585. Differential Revision: https://phab.mercurial-scm.org/D6624
Fri, 28 Jun 2019 00:35:52 +0530 abort: added support for histedit
Taapas Agrawal <taapas2897@gmail.com> [Fri, 28 Jun 2019 00:35:52 +0530] rev 42584
abort: added support for histedit This patch adds the support for `histedit` in `hg abort` plan. As seperate `hgaborthistedit()` function is created to handle independent calls for abortion of `histedit`. This function is then registered as `abortfunc` for state detection API. hg abort in case of `histedit` also supports ` history-editing-backup` config option. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6582
Sun, 23 Jun 2019 23:11:35 +0530 abort: added support for rebase
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 23:11:35 +0530] rev 42583
abort: added support for rebase This adds support of `rebase` to `hg abort` plan. An independent abort logic for `rebase` is created under `abortrebase()` function. For this a seperate `rebaseruntime` object is created under the function to handle an unfinished `rebasestate` and abort that using abort logic under `_prepareabortorcontinue`. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6568
Sun, 23 Jun 2019 22:31:31 +0530 abort: added support for graft
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 22:31:31 +0530] rev 42582
abort: added support for graft This adds support of `graft` to `hg abort` plan. The patch creates a seperate function `cmdutil.hgabortgraft` so that abort logic for graft can be called independently. This logic is registered to the statedetection API as `abortfunc`. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6567
Sun, 23 Jun 2019 20:58:01 +0530 abort: added logic for of hg abort
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 20:58:01 +0530] rev 42581
abort: added logic for of hg abort This is part of `GSoC19` project `Implement abort and continue commands`. This patch is part of the `abort plan`. This adds the basic logic for `hg abort`. This command aborts an multistep operation like graft, histedit, rebase, merge and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under `statemod`. This API is extended to support `hg abort` by adding a method to register the abort logic as a function (here `abortfunc`). Once the unfinished operation is determined the registered logic is used to abort the command. The benefit of this kind of framework is that any new extension developed can support `hg abort` by registering the command and logic under statedetection API. `hg abort` currently supports `--dry-run/-n` flag only. It is used to dry run `hg abort` Further patches sequentially add support for `graft`, `rebase`, `unshelve`, `histedit` and `merge`. Differential Revision: https://phab.mercurial-scm.org/D6566
Tue, 09 Jul 2019 10:09:46 -0400 merge with stable
Augie Fackler <augie@google.com> [Tue, 09 Jul 2019 10:09:46 -0400] rev 42580
merge with stable
Tue, 09 Jul 2019 12:58:29 +0300 merge: disallow merge abort in case of an unfinished operation (issue6160)
Taapas Agrawal <taapas2897@gmail.com> [Tue, 09 Jul 2019 12:58:29 +0300] rev 42579
merge: disallow merge abort in case of an unfinished operation (issue6160) This patch disallows `hg merge --abort` in case an operation of higher precedence i.e unshelve, rebase, histedit are in unfinished states. This is done so as to avoid partial abort of these operations in case merge abort is called at an interrupted step. The patch adds a `cmdutil.getunfinishedstate` function which checks for operations under progress and returns a `statecheck` object for it. Differential Revision: https://phab.mercurial-scm.org/D6607
Mon, 08 Jul 2019 15:01:18 -0700 relnotes: document new range-select mechanism in crecord
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 15:01:18 -0700] rev 42578
relnotes: document new range-select mechanism in crecord Differential Revision: https://phab.mercurial-scm.org/D6622
Fri, 05 Jul 2019 00:17:26 +0530 statecheck: updated docstrings related to afterresolvedstates
Taapas Agrawal <taapas2897@gmail.com> [Fri, 05 Jul 2019 00:17:26 +0530] rev 42577
statecheck: updated docstrings related to afterresolvedstates Differential Revision: https://phab.mercurial-scm.org/D6606
Mon, 08 Jul 2019 14:01:01 -0400 extdata: avoid crashing inside subprocess when we get a revset parse error
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 14:01:01 -0400] rev 42576
extdata: avoid crashing inside subprocess when we get a revset parse error Differential Revision: https://phab.mercurial-scm.org/D6616
Mon, 08 Jul 2019 13:57:44 -0400 extdata: demonstrate bad behavior when a subprocess emits garbage
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:57:44 -0400] rev 42575
extdata: demonstrate bad behavior when a subprocess emits garbage Differential Revision: https://phab.mercurial-scm.org/D6615
Sun, 07 Jul 2019 23:04:55 -0700 py3: don't run source transformer on hgext3rd (extensions)
Martin von Zweigbergk <martinvonz@google.com> [Sun, 07 Jul 2019 23:04:55 -0700] rev 42574
py3: don't run source transformer on hgext3rd (extensions) It's unclear why the source transformer runs on hgext3rd. It's been like that since it was introduced in 1c22400db72d (mercurial: implement a source transforming module loader on Python 3, 2016-07-04), and that commit didn't say anything about it (but it says that it doesn't have "support [...] for extensions"). I find that the current handling of hgext3rd just makes it harder to convert extensions to Python 3. It makes you convert a bunch of strings passed to getattr() and kwargs[] to r'' that could otherwise have been left alone. It's also really confusing that the source transformer runs when you import the extension as "extensions.foo=", but not as "extension.foo=/some/path". I suppose there is small number of (very simple) extensions that would have worked without this patch that would now be broken. It seems okay to me to break those. Differential Revision: https://phab.mercurial-scm.org/D6614
Mon, 08 Jul 2019 13:10:34 -0700 crecord: provide 'X' as a range-select mechanism
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:10:34 -0700] rev 42573
crecord: provide 'X' as a range-select mechanism Differential Revision: https://phab.mercurial-scm.org/D6621
Mon, 08 Jul 2019 13:06:46 -0700 crecord: make KEY_ENTER usable in tests (by not updating UI)
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:06:46 -0700] rev 42572
crecord: make KEY_ENTER usable in tests (by not updating UI) Differential Revision: https://phab.mercurial-scm.org/D6620
Mon, 08 Jul 2019 12:38:37 -0700 crecord: fix if -> elif when handling key presses
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:38:37 -0700] rev 42571
crecord: fix if -> elif when handling key presses This shouldn't actually change any behavior, I only noticed it since I started using KEY_UP in tests, and it was complaining when it got down to the ^L handler that initscr hadn't been called yet. Differential Revision: https://phab.mercurial-scm.org/D6619
Mon, 08 Jul 2019 12:17:06 -0700 crecord: add "x" alias for space, remove test-only "TOGGLE" alias
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:17:06 -0700] rev 42570
crecord: add "x" alias for space, remove test-only "TOGGLE" alias Differential Revision: https://phab.mercurial-scm.org/D6618
Mon, 08 Jul 2019 12:15:37 -0700 crecord: stop using test-only "X" as alternative for "c"
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:15:37 -0700] rev 42569
crecord: stop using test-only "X" as alternative for "c" Differential Revision: https://phab.mercurial-scm.org/D6617
Sat, 06 Jul 2019 22:19:36 +0530 graft: moved abortgraft and readgraft to cmdutil
Taapas Agrawal <taapas2897@gmail.com> [Sat, 06 Jul 2019 22:19:36 +0530] rev 42568
graft: moved abortgraft and readgraft to cmdutil This patch moves `abortgraft` and `readgraft` to `cmdutil`. Various callers are updated accordingly. This is done because these serve as ulitlity functions for command `graft` and so that new functions regarding graft can be built from them. Differential Revision: https://phab.mercurial-scm.org/D6608
Thu, 20 Jun 2019 14:33:42 -0400 cleanup: use named constants for second arg to .seek()
Augie Fackler <augie@google.com> [Thu, 20 Jun 2019 14:33:42 -0400] rev 42567
cleanup: use named constants for second arg to .seek() Differential Revision: https://phab.mercurial-scm.org/D6556
Thu, 20 Jun 2019 14:45:52 -0700 patch: use a short, fixed-size message for last line of prompt (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 14:45:52 -0700] rev 42566
patch: use a short, fixed-size message for last line of prompt (issue6158) See issue6158 and the previous commit for examples of what might go wrong if we have some combinations of readline version and terminal and need to wrap the line. Briefly: readline may not display the beginning of the last line of the prompt, or it may print over it with the end of the prompt, making it difficult for users to know what's going on. Differential Revision: https://phab.mercurial-scm.org/D6563
Thu, 20 Jun 2019 11:40:47 -0700 filemerge: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 11:40:47 -0700] rev 42565
filemerge: make last line of prompts <40 english chars (issue6158) I've chosen <40 as the target so that other languages that may have a 2x blowup in character count can still have a chance to fit into an 80 column screen. Previously, we would show a prompt like: ``` keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path? ``` On at least some systems, if readline was in use then the last line of the prompt would be wrapped strangely if it couldn't fit entirely on one line. This strange wrapping may be just a carriage return without a line feed, overwriting the beginning of the line; example (100 columns wide, 65 character filename, and yes there's 10 spaces on the end, I assume this is to handle the user inputting longest word we provide as an option, "unresolved"): ``` ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon ``` In some cases it may partially wrap onto the next line, but still be missing earlier parts in the line, such as below (60 columns wide, 65 character filename): ``` rev], or leave (u)nresolved for some/long/dir/name/that/do s/not/work/well/with/readline/file.txt? ``` With this fix, this looks like this on a 60 column screen: ``` tool vim_with_markers (for pattern some/long/dir/name/that/d oes/not/work/well/with/readline/file.txt) can't handle binar y tool meld can't handle binary tool vim_with_markers can't handle binary tool internal:merge3 can't handle binary tool merge can't handle binary no tool found to merge some/long/dir/name/that/does/not/work /well/with/readline/file.txt file 'some/long/dir/name/that/does/not/work/well/with/readli ne/file.txt' needs to be resolved. You can keep (l)ocal [working copy], take (o)ther [merge rev ], or leave (u)nresolved. What do you want to do? ``` Differential Revision: https://phab.mercurial-scm.org/D6562
Tue, 09 Jul 2019 10:07:35 -0400 Added signature for changeset 97ada9b8d51b stable
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:35 -0400] rev 42564
Added signature for changeset 97ada9b8d51b
Tue, 09 Jul 2019 10:07:33 -0400 Added tag 5.0.2 for changeset 97ada9b8d51b stable
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:33 -0400] rev 42563
Added tag 5.0.2 for changeset 97ada9b8d51b
Mon, 08 Jul 2019 13:12:20 -0400 posix: always seek to EOF when opening a file in append mode stable 5.0.2
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:12:20 -0400] rev 42562
posix: always seek to EOF when opening a file in append mode Python 3 already does this, so skip it there. Consider the program: #include <stdio.h> int main() { FILE *f = fopen("narf", "w"); fprintf(f, "narf\n"); fclose(f); f = fopen("narf", "a"); printf("%ld\n", ftell(f)); fprintf(f, "troz\n"); printf("%ld\n", ftell(f)); return 0; } on macOS, FreeBSD, and Linux with glibc, this program prints 5 10 but on musl libc (Alpine Linux and probably others) this prints 0 10 By my reading of https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html this is technically correct, specifically: > Opening a file with append mode (a as the first character in the > mode argument) shall cause all subsequent writes to the file to be > forced to the then current end-of-file, regardless of intervening > calls to fseek(). in other words, the file position doesn't really matter in append-mode files, and we can't depend on it being at all meaningful unless we perform a seek() before tell() after open(..., 'a'). Experimentally after a .write() we can do a .tell() and it'll always be reasonable, but I'm unclear from reading the specification if that's a smart thing to rely on. This matches what we do on Windows and what Python 3 does for free, so let's just be consistent. Thanks to Yuya for the idea.
Sat, 06 Jul 2019 19:55:29 -0400 tweakdefaults: make hg resolve require --re-merge flag to re-merge
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 06 Jul 2019 19:55:29 -0400] rev 42561
tweakdefaults: make hg resolve require --re-merge flag to re-merge Pulkit suggested it in https://phab.mercurial-scm.org/D4379, and a discussion with Octobus people reminded me that people still use the error-prone default behavior of `hg resolve`. Differential Revision: https://phab.mercurial-scm.org/D6610
Thu, 04 Jul 2019 21:29:28 +0530 unshelve: rename _dounshelve() to dounshelve()
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 04 Jul 2019 21:29:28 +0530] rev 42560
unshelve: rename _dounshelve() to dounshelve() This is a follow-up patch to 3de4f17f4824. Differential Revision: https://phab.mercurial-scm.org/D6605
Mon, 01 Jul 2019 15:07:31 +0200 rust: remove Deref in favor of explicit methods
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 15:07:31 +0200] rev 42559
rust: remove Deref in favor of explicit methods Differential Revision: https://phab.mercurial-scm.org/D6593
Mon, 01 Jul 2019 10:53:36 +0200 rust: simplify overly complicated expression
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 10:53:36 +0200] rev 42558
rust: simplify overly complicated expression Differential Revision: https://phab.mercurial-scm.org/D6592
Mon, 01 Jul 2019 10:50:18 +0200 rust: run rfmt on all hg-core/hg-cpython code
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 10:50:18 +0200] rev 42557
rust: run rfmt on all hg-core/hg-cpython code Differential Revision: https://phab.mercurial-scm.org/D6591
Wed, 03 Jul 2019 10:06:39 +0800 move: --force flag forcibly moves, not copies stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:06:39 +0800] rev 42556
move: --force flag forcibly moves, not copies
Wed, 03 Jul 2019 10:01:51 +0800 copy: correct synopsis by making SOURCE a required argument stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:01:51 +0800] rev 42555
copy: correct synopsis by making SOURCE a required argument
Tue, 02 Jul 2019 10:53:29 +0200 debugrevlog: fix average size computation for empty data (issue6167) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Jul 2019 10:53:29 +0200] rev 42554
debugrevlog: fix average size computation for empty data (issue6167) If the file has no full snapshot (eg: was always empty), `hg debugrevlog` would fails when trying to compute their average size.
Mon, 01 Jul 2019 16:25:51 -0700 changelog: fix handling of empty copy entries in changeset
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Jul 2019 16:25:51 -0700] rev 42553
changelog: fix handling of empty copy entries in changeset Before this patch, when an empty value was found in the changeset, we would get a ValueError, which would result in None being returned for addedfiles/removedfiles and p1copies/p2copies. That made 278dcb24e535 (copies: write empty entries in changeset when also writing to filelog, 2019-04-23) ineffective at helping the read path not look for copies in the filelogs. Differential Revision: https://phab.mercurial-scm.org/D6595
Sun, 30 Jun 2019 17:52:57 +0530 relnotes: document the new --force-close-branch flag
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 17:52:57 +0530] rev 42552
relnotes: document the new --force-close-branch flag Differential Revision: https://phab.mercurial-scm.org/D6590
Tue, 11 Jun 2019 20:53:14 +0300 py3: hack around inconsistency of type of name passed to DNSQuestion
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 11 Jun 2019 20:53:14 +0300] rev 42551
py3: hack around inconsistency of type of name passed to DNSQuestion I don't like this patch but this is the easiest way I could fix it. There are some callers which pass name which is bytes, some pass name which is str. I just encode() that if that's str. This does makes test-paths.t pass, but I am not confident whether the whole of zeroconf will work on py3 or not. Differential Revision: https://phab.mercurial-scm.org/D6511
Tue, 11 Jun 2019 20:48:59 +0300 py3: add r'' prefixes and do ('%d' % int) instead of str(int)
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 11 Jun 2019 20:48:59 +0300] rev 42550
py3: add r'' prefixes and do ('%d' % int) instead of str(int) This addresses more failures related to zeroconf on py3. Differential Revision: https://phab.mercurial-scm.org/D6510
Sat, 02 Feb 2019 12:07:31 -0800 zeroconf: port to Python 3
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 02 Feb 2019 12:07:31 -0800] rev 42549
zeroconf: port to Python 3 Since we're using the source transformer on Python 3, calls into Zeroconf and return values from it are generally bytes. But various socket functions require str on Python 3. This commit contains enough changes to coerce test-paths.t into passing on Python 3. I suspect there are still a handful of bugs on Python 3. But the tests do pass. Differential Revision: https://phab.mercurial-scm.org/D5805
Fri, 28 Jun 2019 16:40:36 -0700 copies: return only path from _tracefile() since that's all caller needs
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 16:40:36 -0700] rev 42548
copies: return only path from _tracefile() since that's all caller needs Differential Revision: https://phab.mercurial-scm.org/D6587
Sun, 30 Jun 2019 13:04:26 +0530 extensions: add shelve to _builtin
Navaneeth Suresh <navaneeths1998@gmail.com> [Sun, 30 Jun 2019 13:04:26 +0530] rev 42547
extensions: add shelve to _builtin This is a follow-up patch to 3de4f17f4824. This adds `shelve` to `extensions._builtin` so that the shelve extension is silently ignored. Differential Revision: https://phab.mercurial-scm.org/D6589
Sun, 30 Jun 2019 15:10:56 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Jun 2019 15:10:56 +0900] rev 42546
merge with stable
Sat, 29 Jun 2019 23:23:07 -0400 bookmarks: backout the attempt to fix the delete race stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 29 Jun 2019 23:23:07 -0400] rev 42545
bookmarks: backout the attempt to fix the delete race This backs out 044045dce23a because it broke a bunch of tests on Windows. Yuya's theory is that we still rely on in-memory changelog data to be flushed out of the transaction.
Fri, 28 Jun 2019 14:13:00 -0700 automv: access status fields by name, not index
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 14:13:00 -0700] rev 42544
automv: access status fields by name, not index Differential Revision: https://phab.mercurial-scm.org/D6586
Fri, 28 Jun 2019 14:07:09 -0700 automv: use public API for getting copies
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 14:07:09 -0700] rev 42543
automv: use public API for getting copies Differential Revision: https://phab.mercurial-scm.org/D6585
Sat, 18 May 2019 15:44:23 +0530 commit: add --force-close-branch flag to close a non-head changeset
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 18 May 2019 15:44:23 +0530] rev 42542
commit: add --force-close-branch flag to close a non-head changeset While closing branch from a changeset which is not a branch head current implementation abort this action in every case but, there can be the situations where the changeset is not a local head but could be a remote head. This patch adds the functionality to bypass the "abort: can only close branch heads" by introducing --force-close-branch flag. Test case changes demonstrate the new functionality added. Differential Revision: https://phab.mercurial-scm.org/D6490
Fri, 28 Jun 2019 21:31:34 +0530 shelve: move shelve extension to core
Navaneeth Suresh <navaneeths1998@gmail.com> [Fri, 28 Jun 2019 21:31:34 +0530] rev 42541
shelve: move shelve extension to core Until now, `shelve` was bootstrapped as an extension. This patch adds `shelve` on core. Differential Revision: https://phab.mercurial-scm.org/D6553
Fri, 28 Jun 2019 22:57:48 +0530 shelve: remove rebase.clearstatus()
Navaneeth Suresh <navaneeths1998@gmail.com> [Fri, 28 Jun 2019 22:57:48 +0530] rev 42540
shelve: remove rebase.clearstatus() This is a follow-up patch to c829749e7639. After this, shelve will be no longer dependent on rebase. This removes rebase.clearstatus() from shelve. Differential Revision: https://phab.mercurial-scm.org/D6584
Thu, 20 Jun 2019 00:59:16 +0530 shelve: removed redundant merge detection method
Taapas Agrawal <taapas2897@gmail.com> [Thu, 20 Jun 2019 00:59:16 +0530] rev 42539
shelve: removed redundant merge detection method Differential Revision: https://phab.mercurial-scm.org/D6547
Wed, 05 Jun 2019 17:58:34 +0200 rust-dirstate: call new "dirs" rust implementation from Python
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Jun 2019 17:58:34 +0200] rev 42538
rust-dirstate: call new "dirs" rust implementation from Python This is a simple module attribute replacement, will take precedence over the Python and C implementations. Differential Revision: https://phab.mercurial-scm.org/D6395
Thu, 16 May 2019 18:03:42 +0200 rust-dirstate: add "dirs" rust-cpython binding
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 May 2019 18:03:42 +0200] rev 42537
rust-dirstate: add "dirs" rust-cpython binding There is an obvious performance and memory issue with those bindings on larger repos as it copies and allocates everything at once, round-trip. Like in the previous patch series, this is only temporary and will only get better once we don't have large data structures going to and from Python. Differential Revision: https://phab.mercurial-scm.org/D6394
Thu, 16 May 2019 18:03:06 +0200 rust-dirstate: add "dirs" Rust implementation
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 May 2019 18:03:06 +0200] rev 42536
rust-dirstate: add "dirs" Rust implementation Following the work done in d1786c1d34fa and working towards the goal of a complete Rust implementation of the dirstate, this rewrites the `dirs` class. There is already a C implementation, which relies heavily on CPython hacks and protocol violations for performance, so I don't expect this to perform as well for now, as this is very straight-forward code. The immediate benefits are new high-level documentation and some unit tests. Differential Revision: https://phab.mercurial-scm.org/D6393
Fri, 21 Jun 2019 00:26:07 +0530 relnotes: added description about statemod._statecheck
Taapas Agrawal <taapas2897@gmail.com> [Fri, 21 Jun 2019 00:26:07 +0530] rev 42535
relnotes: added description about statemod._statecheck Differential Revision: https://phab.mercurial-scm.org/D6557
Fri, 28 Jun 2019 03:15:39 +0530 statecheck: shifted defaults to addunfinished()
Taapas Agrawal <taapas2897@gmail.com> [Fri, 28 Jun 2019 03:15:39 +0530] rev 42534
statecheck: shifted defaults to addunfinished() This shifts the definitions and defaults of `_statecheck()` class to `addunfinished()` registration method. Differential Revision: https://phab.mercurial-scm.org/D6583
Thu, 20 Jun 2019 11:40:08 +0530 statecheck: added support for cmdutil.afterresolvedstates
Taapas Agrawal <taapas2897@gmail.com> [Thu, 20 Jun 2019 11:40:08 +0530] rev 42533
statecheck: added support for cmdutil.afterresolvedstates This removes `afterresolvedstates` from `cmdutil` and adds support for it in `_statecheck` class. A new flag `continueflag` is added to the class to check whether an operation supports `--continue` option or not. Tests remain unchanged. Differential Revision: https://phab.mercurial-scm.org/D6551
Sun, 09 Jun 2019 02:12:58 +0530 statecheck: added support for STATES
Taapas Agrawal <taapas2897@gmail.com> [Sun, 09 Jun 2019 02:12:58 +0530] rev 42532
statecheck: added support for STATES This removes `STATES` from `state.py` and adds support to `statecheck` class to handle its features. `getrepostate()` function is modified accordingly. This adds a method 'cmdutil.addunfinished()' for appending to the unfinishedstate list so as to keep 'merge' and 'bisect' at the last. This also makes two separate message formats for `checkunfinished()` and `getrepostate()` as there were previously present. Results of test changed are shown. Differential Revision: https://phab.mercurial-scm.org/D6503
Sun, 09 Jun 2019 01:13:13 +0530 state: moved cmdutil.STATES and utilities to state.py
Taapas Agrawal <taapas2897@gmail.com> [Sun, 09 Jun 2019 01:13:13 +0530] rev 42531
state: moved cmdutil.STATES and utilities to state.py This commit moves `cmdutil.STATES` and adjoining functions to `state.py`. The existing users are updated accordingly. Tests remain unchanged. Differential Revision: https://phab.mercurial-scm.org/D6502
Sun, 09 Jun 2019 00:43:36 +0530 state: created new class statecheck to handle unfinishedstates
Taapas Agrawal <taapas2897@gmail.com> [Sun, 09 Jun 2019 00:43:36 +0530] rev 42530
state: created new class statecheck to handle unfinishedstates For the purpose of handling states for various multistep operations like `hg graft`, `hg histedit`, `hg bisect` et al a new class called statecheck is created .This will help in having a unified approach towards these commands and handle them with ease. The class takes in 4 basic arguments which include the name of the command, the name of the state file associated with it , clearable flag , allowcommit flag. This also also adds the support of`checkunfinished()` and `clearunfinished()` to the class. Tests remain unchanged. Differential Revision: https://phab.mercurial-scm.org/D6501
Sat, 08 Jun 2019 23:43:53 +0530 states: moved cmdutil.unfinishedstates to state.py
Taapas Agrawal <taapas2897@gmail.com> [Sat, 08 Jun 2019 23:43:53 +0530] rev 42529
states: moved cmdutil.unfinishedstates to state.py This moves `cmdutil.unfinishedstates`, `checkunfinished()`,`clearunfinished()` to `state.py`. the already existing users of this module are updated accordingly. Test results remain unchanged. Differential Revision: https://phab.mercurial-scm.org/D6484
Mon, 24 Jun 2019 16:01:22 -0700 rebase: fix in-memory rebasing of copy of empty file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 24 Jun 2019 16:01:22 -0700] rev 42528
rebase: fix in-memory rebasing of copy of empty file Classic Python mistake of unintentionally treating None and empty string the same. Differential Revision: https://phab.mercurial-scm.org/D6570
Mon, 24 Jun 2019 16:07:59 -0700 tests: demonstrate broken in-memory rebase of copy to empty file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 24 Jun 2019 16:07:59 -0700] rev 42527
tests: demonstrate broken in-memory rebase of copy to empty file Differential Revision: https://phab.mercurial-scm.org/D6569
Tue, 25 Jun 2019 14:23:02 -0700 zsh: enable completion support for chg as well
Kyle Lippincott <spectral@google.com> [Tue, 25 Jun 2019 14:23:02 -0700] rev 42526
zsh: enable completion support for chg as well When verifying this change, you may need to clear/rebuild the completion cache; I did this by deleting the ~/.zcompdump file and then starting a new shell. Differential Revision: https://phab.mercurial-scm.org/D6574
Tue, 25 Jun 2019 19:32:08 -0700 py3: make catapult usable from the test runner in py3
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Tue, 25 Jun 2019 19:32:08 -0700] rev 42525
py3: make catapult usable from the test runner in py3 Differential Revision: https://phab.mercurial-scm.org/D6577
Tue, 25 Jun 2019 19:30:24 -0700 py3: use integer division for the value passed to xrange
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Tue, 25 Jun 2019 19:30:24 -0700] rev 42524
py3: use integer division for the value passed to xrange Differential Revision: https://phab.mercurial-scm.org/D6576
Tue, 25 Jun 2019 19:28:41 -0700 pycompat: make fewer assumptions about sys.executable
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Tue, 25 Jun 2019 19:28:41 -0700] rev 42523
pycompat: make fewer assumptions about sys.executable There are many Python "bundlers" which create an archive to run a Python binary from, and they may not set sys.executable at all - handle that case properly, especially to run tests. Differential Revision: https://phab.mercurial-scm.org/D6575
Thu, 27 Jun 2019 11:39:35 +0200 update: fix spurious unclean status bug shown by previous commit
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Thu, 27 Jun 2019 11:39:35 +0200] rev 42522
update: fix spurious unclean status bug shown by previous commit The crux of the problem is: - the dirstate is corrupted (the sizes/dates are assigned to the wrong files) - because when worker.worker is used with a return value (batchget in merge.py here), the return value when worker.worker effectively parallelizes is permuted - this is because worker.worker's partition of input and combination of output values are not inverses of one another: it split [1,2,3,4,5,6] into [[1,3,5],[2,4,6]], but combines that into [1,3,5,2,4,6]. Given that worker.worker doesn't call its function argument on contiguous chunks on the input arguments, sticking with lists means we'd need to know the relation between the inputs of worker.worker function argument (for instance, requiring that every input element is mapped to exactly one output element). It seems better to instead switch return values to dicts, which can combined reliably with a straighforward restriction. Differential Revision: https://phab.mercurial-scm.org/D6581
Thu, 27 Jun 2019 11:09:09 +0200 tests: show bug in update introduced in 87a34c767384
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Thu, 27 Jun 2019 11:09:09 +0200] rev 42521
tests: show bug in update introduced in 87a34c767384 As reported by Martin at https://phab.mercurial-scm.org/D6475. Differential Revision: https://phab.mercurial-scm.org/D6580
Wed, 26 Jun 2019 05:20:02 -0700 copies: document how 'copies' dict instances are reused
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Jun 2019 05:20:02 -0700] rev 42520
copies: document how 'copies' dict instances are reused We avoid copying these instances as much as we can, so it's not obvious what's safe to do with them. This patch tries to explain what is safe and what is not. Differential Revision: https://phab.mercurial-scm.org/D6578
Thu, 20 Jun 2019 10:58:14 -0700 copies: simplify merging of copy dicts on merge commits
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jun 2019 10:58:14 -0700] rev 42519
copies: simplify merging of copy dicts on merge commits After we removed some filtering in 35d674a3d5db (copies: don't filter out copy targets created on other side of merge commit, 2019-04-18), we will always include all entries from "copies1", so we can simplify the code based on that. Differential Revision: https://phab.mercurial-scm.org/D6561
Thu, 20 Jun 2019 10:42:16 -0700 copies: remove a redundant matcher filtering in _changesetforwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jun 2019 10:42:16 -0700] rev 42518
copies: remove a redundant matcher filtering in _changesetforwardcopies() We filter before pushing items on the queue, so we don't need to filter after popping. Differential Revision: https://phab.mercurial-scm.org/D6560
Thu, 20 Jun 2019 10:51:23 -0700 copies: delete obsolete comment in _changesetforwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jun 2019 10:51:23 -0700] rev 42517
copies: delete obsolete comment in _changesetforwardcopies() IIRC, the comment applied to the filtering we did before 35d674a3d5db (copies: don't filter out copy targets created on other side of merge commit, 2019-04-18). Differential Revision: https://phab.mercurial-scm.org/D6559
Mon, 24 Jun 2019 14:28:21 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 24 Jun 2019 14:28:21 -0400] rev 42516
merge with stable
Sat, 22 Jun 2019 23:04:52 -0400 help: add a missing blank line to unhide `revlog-compression` stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 22 Jun 2019 23:04:52 -0400] rev 42515
help: add a missing blank line to unhide `revlog-compression` The help was output, but it was elided with "Enabled by default" from the previous item.
Wed, 19 Jun 2019 23:14:10 -0700 copies: avoid reusing the same variable for two different copy dicts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 23:14:10 -0700] rev 42514
copies: avoid reusing the same variable for two different copy dicts "childcopies" is initally the copies the current changeset to one of its children and then we reassign it with the copies from the start of the chain to the child. Let's use different names for these two things. Differential Revision: https://phab.mercurial-scm.org/D6564
Fri, 21 Jun 2019 09:33:57 -0700 drawdag: don't crash when writing copy info to changesets
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jun 2019 09:33:57 -0700] rev 42513
drawdag: don't crash when writing copy info to changesets When writing copies to the changeset, localrepo.commitctx() will call ctx.p1copies() and ctx.p2copies(). These crashed on simplecommitctx because they ended up trying to access the manifest. drawdag doesn't support copies at all, so we can simply override the methods to return empty dicts. Differential Revision: https://phab.mercurial-scm.org/D6565
Fri, 21 Jun 2019 23:35:04 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jun 2019 23:35:04 -0700] rev 42512
merge with stable
Fri, 21 Jun 2019 03:50:40 +0200 bookmarks: actual fix for race condition deleting bookmark stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:40 +0200] rev 42511
bookmarks: actual fix for race condition deleting bookmark This is a simple but efficient fix to prevent the issue tested in `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic approach where filecache learn to depend on each other, but that would not be suitable for stable. The issue is complicated enough that I documented the race and its current solution as inline comment. See this comment for details on the fix.
Fri, 21 Jun 2019 03:50:06 +0200 localrepo: introduce a `_refreshchangelog` method stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:06 +0200] rev 42510
localrepo: introduce a `_refreshchangelog` method See next changeset for usage and documentation for details.
Wed, 19 Jun 2019 17:26:19 +0200 bookmarks: actually trigger the race deleting bookmark in the test stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 17:26:19 +0200] rev 42509
bookmarks: actually trigger the race deleting bookmark in the test The previous committed version of the test did not triggered the race, but this was hidden by a strange behavior from the test runner. So we are moving the test to a slightly more complex that actually trigger the issue.
Wed, 19 Jun 2019 17:26:16 +0200 test: add some assert in the bookrace extension stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 17:26:16 +0200] rev 42508
test: add some assert in the bookrace extension This cannot hurt to have a bit more security in the test extension.
Wed, 19 Jun 2019 05:46:07 +0200 test: factor out the "wait" logic in bookrace stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:46:07 +0200] rev 42507
test: factor out the "wait" logic in bookrace The test is currently not testing the race it is supposed to test. The synchronisation is still valid, but needs to run at a different point. We start with extracting the synchronisation logic for clarity.
Wed, 19 Jun 2019 05:45:44 +0200 test: remove dead code in the bookrace extension stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:45:44 +0200] rev 42506
test: remove dead code in the bookrace extension This code is the remain of a previous version of the code. It is never ran, so we can remove it.
Wed, 19 Jun 2019 05:37:33 +0200 run-tests: stop matching line for missing feature stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:37:33 +0200] rev 42505
run-tests: stop matching line for missing feature Before this change, the following unified test input would silently pass $ echo foo foo (false !) After this change, the "foo" output is properly detected as unexpected. The output of an handful of test had to be updated from broken conditional (that ended up working by chance).
Wed, 19 Jun 2019 10:19:32 -0700 log: pass getcopies() function instead of getrenamed() to displayer (API)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:19:32 -0700] rev 42504
log: pass getcopies() function instead of getrenamed() to displayer (API) This reduces the duplication between the two displayer functions (and between them and scmutil.getcopiesfn()). It's still more code than two patches ago, but there's less duplication. Differential Revision: https://phab.mercurial-scm.org/D6546
Wed, 19 Jun 2019 09:59:45 -0700 copies: create helper for getting all copies for changeset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 09:59:45 -0700] rev 42503
copies: create helper for getting all copies for changeset There are a few places where we get all the copies for a changeset (at least the {file_copies} template and in two places in `hg log --copies` code). These places currently call scmutil.getrenamedfn() to get a caching "getrenamed" function. They all use it in a similar way. We will be able to reuse more code by having a function for getting all the copies for a changeset. This patch introduces such a function. It uses it in the {file_copies} template to show that it works. It relies on the existing scmutil.getrenamedfn() for caching in the filelog-centric case. Differential Revision: https://phab.mercurial-scm.org/D6545
Tue, 18 Jun 2019 23:19:24 -0700 logcmdutil: also check for copies in null revision and working copy
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:19:24 -0700] rev 42502
logcmdutil: also check for copies in null revision and working copy It's safe (and fast) to look for copies in the null revision, and it's incorrect not to look for them in the working copy, so let's look in both places. Differential Revision: https://phab.mercurial-scm.org/D6544
Tue, 18 Jun 2019 23:23:30 -0700 tests: demonstrate missing copy information in working copy with graphlog
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:23:30 -0700] rev 42501
tests: demonstrate missing copy information in working copy with graphlog Differential Revision: https://phab.mercurial-scm.org/D6543
Wed, 19 Jun 2019 10:33:13 -0700 remotefilelog: handle copies in changesets in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:33:13 -0700] rev 42500
remotefilelog: handle copies in changesets in getrenamedfn() override E.g. the {file_copies} template keyword didn't work with copies in changesets before this patch because remotefilelog overrides the getrenamedfn() and didn't handle the changeset-centric case. Differential Revision: https://phab.mercurial-scm.org/D6542
Wed, 19 Jun 2019 11:12:06 -0700 remotefilelog: check if RFL is enabled in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 11:12:06 -0700] rev 42499
remotefilelog: check if RFL is enabled in getrenamedfn() override In 8a0e03f7baf4 (remotefilelog: move most setup from onetimesetup() to uisetup(), 2019-05-01), I said: All the wrappers moved in this patch check if remotefilelog is enabled before they change behavior, so it's safe to always wrap. That was clearly a lie, because getrenamedfn() didn't. That made e.g. `hg log -T {file_copies}` unbearably slow. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6541
Tue, 18 Jun 2019 08:55:23 -0700 relnotes: document template support for `hg root`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 08:55:23 -0700] rev 42498
relnotes: document template support for `hg root` Differential Revision: https://phab.mercurial-scm.org/D6540
Tue, 18 Jun 2019 09:57:06 -0400 remotefilelog: tell runbgcommand to not block on child process startup
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:57:06 -0400] rev 42497
remotefilelog: tell runbgcommand to not block on child process startup These two invocations will always find a binary because they're re-running hg. As a result, we can skip waiting for the subprocess to start running and save a little bit of wall-time. Differential Revision: https://phab.mercurial-scm.org/D6539
Tue, 18 Jun 2019 09:43:27 -0400 procutil: allow callers of runbgcommand to assume the process starts
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:43:27 -0400] rev 42496
procutil: allow callers of runbgcommand to assume the process starts Experimentally starting the subprocess can take as much as 40ms, and for some of our use cases that's frivolous: we know the binary will start, and if it doesn't we'd only ever ignore it and continue anyway. This lets those use cases be faster. Differential Revision: https://phab.mercurial-scm.org/D6537
Tue, 18 Jun 2019 09:58:01 -0400 shallowrepo: remove backwards compat code that predates in-tree remotefilelog
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:58:01 -0400] rev 42495
shallowrepo: remove backwards compat code that predates in-tree remotefilelog Differential Revision: https://phab.mercurial-scm.org/D6538
Tue, 16 Apr 2019 02:53:28 +0530 commit: make the error message more specific while aborting branch closing
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:53:28 +0530] rev 42494
commit: make the error message more specific while aborting branch closing Differential Revision: https://phab.mercurial-scm.org/D6493
Tue, 16 Apr 2019 02:33:54 +0530 commit: add a check if it is trying to close an already closed branch head
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:33:54 +0530] rev 42493
commit: add a check if it is trying to close an already closed branch head It would check if the revision we are going to close is already a closed branch head and print the error message accordingly. Differential Revision: https://phab.mercurial-scm.org/D6491
Mon, 17 Jun 2019 10:53:00 -0700 strip: move checksubstate() to mq (its only caller)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:53:00 -0700] rev 42492
strip: move checksubstate() to mq (its only caller) Differential Revision: https://phab.mercurial-scm.org/D6536
Mon, 17 Jun 2019 10:19:41 -0700 strip: use bailifchanged() instead of reimplementing it
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:19:41 -0700] rev 42491
strip: use bailifchanged() instead of reimplementing it This also means that we get the standard error messages (see changed test cases). Differential Revision: https://phab.mercurial-scm.org/D6535
Mon, 17 Jun 2019 10:40:24 -0700 strip: remove unused excsuffix argument from checklocalchanges()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:40:24 -0700] rev 42490
strip: remove unused excsuffix argument from checklocalchanges() It was only used by mq, and mq now has its own copy of the function. Differential Revision: https://phab.mercurial-scm.org/D6534
Mon, 17 Jun 2019 10:38:50 -0700 mq: remove dependency on strip's checklocalchanges()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:38:50 -0700] rev 42489
mq: remove dependency on strip's checklocalchanges() Some of the functionality in strip.checklocalchanges() was only used by mq, so let's move it to mq so we can clean up strip. Differential Revision: https://phab.mercurial-scm.org/D6533
Thu, 02 May 2019 23:39:33 -0700 copies: avoid calling matcher if matcher.always()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 May 2019 23:39:33 -0700] rev 42488
copies: avoid calling matcher if matcher.always() When storing copy information in the changesets (experimental.copies.read-from=changeset-only), this patch speeds up hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2 from 5.9s to 4.7s. At the start of this series (b162229e), that command took 18min. Differential Revision: https://phab.mercurial-scm.org/D6422
Thu, 18 Apr 2019 21:21:44 -0700 copies: avoid unnecessary copying of copy dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:21:44 -0700] rev 42487
copies: avoid unnecessary copying of copy dict When storing copy information in the changesets, this patch speeds up hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2 from 11s to 5.9s. That command takes 6.2s when storing copy information in filelogs. Differential Revision: https://phab.mercurial-scm.org/D6421
Thu, 18 Apr 2019 21:22:14 -0700 copies: don't filter out copy targets created on other side of merge commit
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:22:14 -0700] rev 42486
copies: don't filter out copy targets created on other side of merge commit If file X is copied to Y on one side of merge and the other side creates Y (no copy), we would not mark that as copy. In the changeset-centric pathcopies() version, that was done by checking if the copy target existed on the other branch. Even though merge commits are pretty uncommon, it still turned out to be too expensive to load the manifest of the parents of merge commits. In a repo of mozilla-unified converted to storing copies in changesets, about 2m30s of `hg debugpathcopies FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE` is spent on this check of merge commits. I tried to think of a way of storing more information in the changesets in order to cheaply detect these cases, but I couldn't think of a solution. So this patch simply removes those checks. For reference, these extra copies are reported from the aforementioned command after this patch: browser/base/content/sanitize.js -> browser/modules/Sanitizer.jsm testing/mozbase/mozprocess/tests/process_normal_finish_python.ini -> testing/mozbase/mozprocess/tests/process_normal_finish.ini testing/mozbase/mozprocess/tests/process_waittimeout_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout.ini testing/mozbase/mozprocess/tests/process_waittimeout_10s_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout_10s.ini Since these copies were created on one side of some merge, it still seems reasonable to include them, so I'm not even sure it's worse than filelog pathcopies(), just different. Differential Revision: https://phab.mercurial-scm.org/D6420
Thu, 18 Apr 2019 00:40:53 -0700 copies: do full filtering at end of _changesetforwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:40:53 -0700] rev 42485
copies: do full filtering at end of _changesetforwardcopies() As mentioned earlier, pathcopies() is very slow when copies are stored in the changeset. Most of the cost comes from calling _chain() for every changeset, which is slow because it needs to read manifests. It needs to read manifests to be able to filter out copies that are were created in one commit and then deleted. (It also filters out copies that were created from a file that didn't exist in the starting revision, but that's a fixed revision across calls to _chain(), so it's much cheaper.) This patch changes from _chainandfilter() to just _chain() in the main loop in _changesetforwardcopies(). It instead removes copies that have subsequently been removed by using ctx.filesremoved(). We thus rely on that to be fast. It timed this command in mozilla-unified: hg debugpathcopies FIREFOX_59_0b3_BUILD2 FIREFOX_BETA_59_END It took 18s before and 1.1s after. It's still faster when copy information is stored in filelogs: 0.70s. It also still gets slow when there are merge commits involved, because we read manifests there too. We'll deal with that later. Differential Revision: https://phab.mercurial-scm.org/D6419
Sat, 15 Jun 2019 10:58:53 +0900 rust-filepatterns: add comment about Windows path handling
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:58:53 +0900] rev 42484
rust-filepatterns: add comment about Windows path handling As I replied to the Phabricator message, this is wrong. And I even suspect it wouldn't compile because of multiple type mismatches. I think, in Rust where type system is rock solid, we can live with UTF-8 strings except for the bottom storage layer and the top UI/command layer. We'll still have to get around undecodable characters not to be lost, but I think it's okay to drop such filenames from match result if they don't match in UTF-8 world, not in Latin-1 world.
Sat, 15 Jun 2019 10:35:53 +0900 rust-filepatterns: silence warning of non_upper_case_globals
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:53 +0900] rev 42483
rust-filepatterns: silence warning of non_upper_case_globals
Sat, 15 Jun 2019 10:35:03 +0900 rust: update Cargo.lock to include @generated comment
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:03 +0900] rev 42482
rust: update Cargo.lock to include @generated comment cargo 1.34.0 of Debian sid inserts this comment, and I'm tired of reverting the change every time I do make local. https://github.com/rust-lang/cargo/commit/bd0e4a08471b8bc7957829b4fd294b8985d4fa2d
Mon, 17 Jun 2019 13:21:41 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 17 Jun 2019 13:21:41 -0400] rev 42481
merge with stable
Sun, 16 Jun 2019 12:31:07 +0900 cborutil: fix streamencode() to handle subtypes stable
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Jun 2019 12:31:07 +0900] rev 42480
cborutil: fix streamencode() to handle subtypes Otherwise the template filter 'cbor' could crash because of bytes subclass: ValueError: do not know how to encode <class 'mercurial.encoding.safelocalstr'>
Fri, 14 Jun 2019 00:30:33 -0400 lfs: correct an error in the TODO file
Matt Harbison <matt_harbison@yahoo.com> [Fri, 14 Jun 2019 00:30:33 -0400] rev 42479
lfs: correct an error in the TODO file
Thu, 04 Oct 2018 00:57:11 -0400 cat: don't prefetch files unless the output requires it
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Oct 2018 00:57:11 -0400] rev 42478
cat: don't prefetch files unless the output requires it It's a waste to cache lfs blobs when cat'ing the raw data at best, but a hassle debugging when the blob is missing. I'm not sure if there are other commands that have '{data}' for output, and if there's a general way to prefetch on that keyword. It's interesting that the verbose output seems to leak into the JSON output, but that seems like an existing bug.
Wed, 12 Jun 2019 19:01:49 -0400 tracing: add support for emitting counters
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:49 -0400] rev 42477
tracing: add support for emitting counters Differential Revision: https://phab.mercurial-scm.org/D6526
Wed, 12 Jun 2019 19:01:37 -0400 tracing: extract tracing-active logic to separate function
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:37 -0400] rev 42476
tracing: extract tracing-active logic to separate function I'm about to add support for counters, and want to avoid duplicating this logic. Differential Revision: https://phab.mercurial-scm.org/D6525
Wed, 12 Jun 2019 19:00:46 -0400 catapipe: add support for COUNTER events
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:00:46 -0400] rev 42475
catapipe: add support for COUNTER events Differential Revision: https://phab.mercurial-scm.org/D6524
Wed, 12 Jun 2019 16:08:21 -0400 demandimport: add tracing coverage for Python 3
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 16:08:21 -0400] rev 42474
demandimport: add tracing coverage for Python 3 This makes things feel a little less mysterious when modules are being imported. Differential Revision: https://phab.mercurial-scm.org/D6523
Fri, 14 Jun 2019 10:21:47 -0700 export: don't prefetch *all* files in manifest
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 10:21:47 -0700] rev 42473
export: don't prefetch *all* files in manifest `hg export` only shows changed files, not all files, but we still prefetched all files in cmdutil.export(). The same is true for the other commands calling cmdutil.exportfile(). That meant that `hg export` with remotefilelog (or lfs, I assume) could take much longer than expected because it would download all the files in the repo. Differential Revision: https://phab.mercurial-scm.org/D6532
Fri, 14 Jun 2019 13:50:06 -0700 remotefilelog: remove obsolete filtering of treemanifest directories
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 13:50:06 -0700] rev 42472
remotefilelog: remove obsolete filtering of treemanifest directories I think this has been obsolete since 2cf18f46a1ce (narrow: only walk files within narrowspec also for committed revisions, 2018-09-28). Differential Revision: https://phab.mercurial-scm.org/D6531
Fri, 14 Jun 2019 18:27:50 +0300 py3: add test-dirstate-race2.t to list of passing tests
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 14 Jun 2019 18:27:50 +0300] rev 42471
py3: add test-dirstate-race2.t to list of passing tests This test was added new recently. The py3 buildbot found that it passes, so let's add it to the list of passing tests. Differential Revision: https://phab.mercurial-scm.org/D6530
Fri, 14 Jun 2019 18:25:14 +0530 strip: during merge allow strip only when -f is used
Taapas Agrawal <taapas2897@gmail.com> [Fri, 14 Jun 2019 18:25:14 +0530] rev 42470
strip: during merge allow strip only when -f is used This ensures to abort strip to `hg strip` when we have a merge in progress and allow it only when a `--force` flag is used. Differential Revision: https://phab.mercurial-scm.org/D6529
Fri, 26 Apr 2019 00:48:12 +0200 deltas: set estimated compression upper bound to "3x" instead of "10x"
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:48:12 +0200] rev 42469
deltas: set estimated compression upper bound to "3x" instead of "10x" In pratice, we very rarely observer compression better than "3x" on manifest deltas. Having a more aggressive estimate significantly helps our pathological use case on a private repository. Here are a comparison of timings using different upper bound. Estimated compression | ø | ×10 | ×5 | ×3 | timing | 14.11 | 2.61 | 1.96 | 1.53 | We also tested the impact of this series on an array of public repositories. This shown no impact in either size nor timing. Full data set below for those interested. Size ---- Regarding size, not significant impact have been noticed on neither public nor private repositories. Here are the number we gathered on public repositories: zlib/upperbound | no | 10x | 5x | 3x mercurial | 5 875 730 | 5 875 730 | 5 875 730 | 5 875 730 pypy | 27 782 913 | 27 782 913 | 27 782 913 | 27 782 913 netbeans | 159 161 207 | 159 161 207 | 159 161 207 | 159 959 879 (+0.5%) mozilla-central | 323 841 642 | 323 841 642 | 323 841 642 | 319 867 519 (-2.5%) mozilla-try | 746 649 123 | 746 649 123 | 746 649 123 | 741 155 568 (-0.7%) private-repo | 1 485 287 294 | 1 485 287 294 | 1 485 287 294 | 1 409 248 382 (-5.1%) zstd/upperbound | no | 10x | 5x | 3x mercurial | 5 895 206 | 5 895 206 | 5 895 206 | 5 895 206 pypy | 28 689 230 | 28 689 230 | 28 689 230 | 28 689 230 netbeans | 157 636 387 | 157 636 387 | 157 636 387 | 159 692 678 (+1.3%) mozilla-central | 317 650 281 | 317 650 281 | 317 650 281 | 319 613 603 (+0.6%) mozilla-try | 737 555 275 | 737 555 275 | 737 555 275 | 738 079 473 (+0.1%) private-repo | 1 352 362 982 | 1 352 362 982 | 1 346 961 880 | 1 361 327 384 (+0.7%) Speed ------ Timing gathered using `hg perfrevlogwrite -m`. Value are in seconds. mercurial zlib | no | 10x | 5x | 3x | total | 65.551783 | 65.388887 | 65.260658 | 65.321199 | max | 0.034544 | 0.034571 | 0.034659 | 0.034521 | 99.99% | 0.034544 | 0.034571 | 0.034659 | 0.034521 | zstd | no | 10x | 5x | 3x | total | 49.118449 | 49.054062 | 48.753588 | 48.740230 | max | 0.009338 | 0.009239 | 0.009202 | 0.009178 | 99.99% | 0.007618 | 0.007639 | 0.007626 | 0.007621 | pypy zlib | no | 10x | 5x | 3x | total | 560.865984 | 558.983817 | 559.083815 | 559.349152 | max | 0.219614 | 0.215922 | 0.218112 | 0.218107 | 99.99% | 0.219614 | 0.215922 | 0.218112 | 0.218107 | zstd | no | 10x | 5x | 3x | total | 349.393280 | 347.395819 | 347.185407 | 345.643985 | max | 0.084143 | 0.083536 | 0.081834 | 0.082178 | 99.99% | 0.039445 | 0.039639 | 0.039612 | 0.039175 | netbeans zlib | no | 10x | 5x | 3x | total | 33103.327727 | 33314.932260 | 33211.745233 | 33345.891778 | max | 2.666852 | 2.672059 | 2.662453 | 2.662936 | 99.99% | 2.058772 | 2.070429 | 2.069569 | 2.064653 | zstd | no | 10x | 5x | 3x | total | 20112.102708 | 20095.879719 | 20083.390300 | 20123.221859 | max | 2.063482 | 2.062851 | 2.065229 | 2.060147 | 99.99% | 1.146647 | 1.143794 | 1.142933 | 1.146529 | mozilla zlib | no | 10x | 5x | 3x | total | 41374.102138 | 41418.816773 | 41381.956370 | 41334.280732 | max | 3.383474 | 3.387400 | 3.405711 | 3.387316 | 99.99% | 1.006755 | 1.005954 | 1.007700 | 1.007373 | zstd | no | 10x | 5x | 3x | total | 24689.691520 | 24643.939662 | 24664.630027 | 24664.512714 | max | 1.460822 | 1.449640 | 1.439747 | 1.465304 | 99.99% | 0.527111 | 0.527377 | 0.527807 | 0.527226 |
Mon, 21 Jan 2019 22:46:31 +0100 deltas: skip if projected compressed size is bigger than previous snapshot
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:31 +0100] rev 42468
deltas: skip if projected compressed size is bigger than previous snapshot If we have a delta, we check constraints against a lower bound estimate of the resulting compressed delta. We then checks this projected size against the `size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a further performance boost (timing from `hg perfrevlogwrite`): before: 3.010646 seconds after: 2.609307 seconds
Mon, 21 Jan 2019 22:46:18 +0100 deltas: skip if projected compressed size does not match text size constraint
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:18 +0100] rev 42467
deltas: skip if projected compressed size does not match text size constraint If we have a delta, we check constraints against a lower bound estimate of the resulting compressed delta. We then checks this projected size against the ½ⁿ size constraints. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a further performance boost (timing from `hg perfrevlogwrite`): before: 3.145906 seconds after: 3.010646 seconds
Mon, 21 Jan 2019 22:37:30 +0100 deltas: accept and skip None return for delta info
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:37:30 +0100] rev 42466
deltas: accept and skip None return for delta info They are some extra computation that will shortcut the delta compression if the delta seems hopeless, returning None.
Mon, 21 Jan 2019 22:36:16 +0100 delta: move some delta chain related computation earlier in deltainfo
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:36:16 +0100] rev 42465
delta: move some delta chain related computation earlier in deltainfo They are some more optimization change that will make use of this in the function. So we retrieve the data earlier.
Thu, 25 Apr 2019 22:50:33 +0200 deltas: skip if projected delta size is bigger than previous snapshot
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 25 Apr 2019 22:50:33 +0200] rev 42464
deltas: skip if projected delta size is bigger than previous snapshot Before computing any delta, we get a basic estimation of the delta size we can expect and the resulted compressed value. We then checks this projected size against the `size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a significant performance boost (timing from `hg perfrevlogwrite`): before: 14.115908 seconds after: 3.145906 seconds
Thu, 25 Apr 2019 22:30:14 +0200 deltas: skip if projected delta size does not match text size constraint
Valentin Gatien-Baron <vgatien-baron@janestreet.com>, Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Apr 2019 22:30:14 +0200] rev 42463
deltas: skip if projected delta size does not match text size constraint Before computing any delta, we get a basic estimation of the delta size we can expect and the resulted compressed value. We then checks this projected size against the ½ⁿ size constraints. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. In practice we only perform this new checks for the manifestlog. Manifest log combine two property: it is likely to have delta chain issue and its diffing/compression is fairly predictable. The initial author of this changeset is Valentin Gatien-Baron providing the initial idea and initial testing, Pierre-Yves David later consolidated the code in the right location and run more extensive testing.
Fri, 26 Apr 2019 00:28:22 +0200 revlog: add the option to track the expected compression upper bound
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:28:22 +0200] rev 42462
revlog: add the option to track the expected compression upper bound There are various optimization we can do if we can estimate the size of delta before actually spending CPU compressing them. So we add a attributed dedicated to tracking that. We only use it on Manifest because (1) it structure is quite stable across all Mercurial repository so its compression ratio is fairly universal. This is the revlog with most extreme delta (cf the sparse-revlog optimization). This will be put to use in later changesets. Right now the compression upper bound is set to 10. This is a fairly conservative value (observed value is more around 3), but I prefer to be safe while introducing the optimization principles. We can tune the optimization threshold later.
Wed, 12 Jun 2019 17:30:24 +0100 perf: clarify some of the custom behavior of `perfrevlogwrite`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 17:30:24 +0100] rev 42461
perf: clarify some of the custom behavior of `perfrevlogwrite` This reduce the chance of developers being surprised by special cases.
Wed, 12 Jun 2019 16:56:41 +0100 perf: fix perfrevlogwrite --count documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 16:56:41 +0100] rev 42460
perf: fix perfrevlogwrite --count documentation The help text was copy pasted from the previous option.
Fri, 17 May 2019 00:17:43 +0200 rust: switched to 'cargo rustc' in setup.py
Georges Racinet <georges.racinet@octobus.net> [Fri, 17 May 2019 00:17:43 +0200] rev 42459
rust: switched to 'cargo rustc' in setup.py This is more flexible in the passing of additional flags, also what setuptools_rust does, giving less uncertainty about non-Linux platforms.
Fri, 14 Jun 2019 11:18:06 +0100 rust-cpython: fix build for MacOSX
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 11:18:06 +0100] rev 42458
rust-cpython: fix build for MacOSX MacOSX needs special link flags. Quoting the README of rust-cpython: create a `.cargo/config` with the following content: ``` [target.x86_64-apple-darwin] rustflags = [ "-C", "link-arg=-undefined", "-C", "link-arg=dynamic_lookup", ] ``` This is tested with Python 2.7 (Anaconda install) and Python 3 (Homebrew install)
Fri, 14 Jun 2019 10:57:07 +0100 rust-cpython: management of shared libray suffix
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 10:57:07 +0100] rev 42457
rust-cpython: management of shared libray suffix Before this changeset, the shared library objects suffixes were both (rustc output and Python input) hardcoded to '.so', which is wrong for Python3 and non Linux targets.
Mon, 27 May 2019 16:55:46 -0400 merge: fix race that could cause wrong size in dirstate
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 27 May 2019 16:55:46 -0400] rev 42456
merge: fix race that could cause wrong size in dirstate The problem is that hg merge/update/etc work the following way: 1. figure out what files to update 2. apply the update to disk 3. apply the update to in-memory dirstate 4. write dirstate where step3 looks at the filesystem and assumes it sees the result of step2. If a file is changed between step2 and step3, step3 will record incorrect information in the dirstate. I avoid this by passing the size step3 needs directly from step2, for the common path (not implemented for change/delete conflicts for instance). I didn't fix the same race for the exec bit for now, because it's less likely to be problematic and I had trouble due to the fact that the dirstate stores the permissions differently from the manifest (st_mode vs '' 'l' 'x'), in combination with tests that pretend that symlinks are not supported. However, I moved the lstat from step3 to step2, which should tighten the race window markedly, both for the exec bit and for the mtime. Differential Revision: https://phab.mercurial-scm.org/D6475
Wed, 12 Jun 2019 13:10:52 -0400 worker: support parallelization of functions with return values
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 12 Jun 2019 13:10:52 -0400] rev 42455
worker: support parallelization of functions with return values Currently worker supports running functions that return a progress iterator. Generalize it to handle function that return a progress iterator then a return value. It's unused in this commit, but will be used in the next one. Differential Revision: https://phab.mercurial-scm.org/D6515
Sun, 19 May 2019 16:06:06 -0400 tests: show how the dirstate can end up containing wrong information
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 19 May 2019 16:06:06 -0400] rev 42454
tests: show how the dirstate can end up containing wrong information which can result in bad status output. Concretely, this seems to be easily triggered by having a build system watching the filesystem for changes, and rebuilding files that are both tracked and generated while an update is happening. Differential Revision: https://phab.mercurial-scm.org/D6474
Thu, 23 May 2019 02:05:32 +0200 rust: new rust options in setup.py
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 May 2019 02:05:32 +0200] rev 42453
rust: new rust options in setup.py The --rust global option turns on usage (and by default compilation) of the rust-cpython based mercurial.rustext. Similarly to what's previously done for zstd, there is a --no-rust option for the build_ext subcommand in order not to build mercurial.rustext, allowing for an OS distribution to prebuild it. The HGWITHRUSTEXT environment variable is still honored, and has the same effect as before, but now it works mostly by making the --rust global option defaulting to True, with some special cases for the direct-ffi case (see more about that below) Coincidentally, the --rust flag can also be passed from the make commands, like actually all global options, in the PURE variable make local PURE=--rust This feels inappropriate, though, and we should follow up with a proper make variable for that case. Although the direct-ffi bindings aren't directly useful any more, we keep them at this stage because - they provide a short prototyping path for experiments in which a C extension module has to call into a Rust extension. The proper way of doing that would be to use capsules, and it's best to wait for our pull request onto rust-cpython for that: https://github.com/dgrunwald/rust-cpython/pull/169 - Build support for capsules defined in Rust will probably need to reuse some of what's currently in use for direct-ffi.
Thu, 30 May 2019 09:14:41 +0200 rust: using policy.importrust from Python callers
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 May 2019 09:14:41 +0200] rev 42452
rust: using policy.importrust from Python callers This commit converts all current Python callers of mercurial.rustext to the new policy.importrust system. After this point, going through policy.importrust or policy.importmod (in some more distant future) is mandatory for callers of Rust code outside of Python tests. We felt it to be appropriate to keep Rust-specific tests run inconditionally if the Rust extensions are present.
Wed, 29 May 2019 13:27:56 +0200 rust: module policy with importrust
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 May 2019 13:27:56 +0200] rev 42451
rust: module policy with importrust We introduce two rust+c module policies and a new `policy.importrust()` that makes use of them. This simple approach provides runtime switching of implementations, which is crucial for the performance measurements such as those Octobus does with ASV. It can also be useful for bug analysis. It also has the advantage of making conditionals in Rust callers more uniform, in particular abstracting over specifics like `demandimport` At this point, the build stays unchanged, with the rust-cpython based `rustext` module being built if HGWITHRUSTEXT=cpython. More transparency for the callers, i.e., just using `policy.importmod` would be a much longer term and riskier effort for the following reasons: 1. It would require to define common module boundaries for the three or four cases (pure, c, rust+ext, cffi) and that is premature with the Rust extension currently under heavy development in areas that are outside the scope of the C extensions. 2. It would imply internal API changes that are not currently wished, as the case of ancestors demonstrates. 3. The lack of data or property-like attributes (tp_member and tp_getset) in current `rust-cpython` makes it impossible to achieve direct transparent replacement of pure Python classes by Rust extension code, meaning that the caller sometimes has to be able to make adjustments or provide additional wrapping.
Thu, 13 Jun 2019 23:28:31 +0300 help: add help entry for internals.mergestate
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 13 Jun 2019 23:28:31 +0300] rev 42450
help: add help entry for internals.mergestate This patch adds an entry for `internals.mergestate` as suggested by @marmoute. Most of the help text is taken from `merge.mergestate`. Differential Revision: https://phab.mercurial-scm.org/D6448 Differential Revision: https://phab.mercurial-scm.org/D6528
Wed, 12 Jun 2019 17:22:37 +0100 phabricator: use parents.set to always set dependencies
Ian Moody <moz-ian@perix.co.uk> [Wed, 12 Jun 2019 17:22:37 +0100] rev 42449
phabricator: use parents.set to always set dependencies Now that Mercurial's Phabricator instance has been updated to a version that supports the parents.set transaction on revision.edit we can use that to set dependency relationships in patch stacks instead of abusing the summary. This has the advantage that we can use it on every `phabsend` so commit reordering is picked up without spamming changes like abusing the summary would, and using parents.set will clear previous parents unlike parents.add. Differential Revision: https://phab.mercurial-scm.org/D6514
Fri, 31 May 2019 10:12:56 -0700 help: remove repeated word in 'hg help rebase'
amalloy [Fri, 31 May 2019 10:12:56 -0700] rev 42448
help: remove repeated word in 'hg help rebase' Specifically, the second 'with' in 'with which to merge with'. Differential Revision: https://phab.mercurial-scm.org/D6483
Mon, 10 Jun 2019 15:35:06 -0700 rebase: tweak description of inmemory working even w/ dirty working dir
Kyle Lippincott <spectral@google.com> [Mon, 10 Jun 2019 15:35:06 -0700] rev 42447
rebase: tweak description of inmemory working even w/ dirty working dir One of our users was confused because they read this, and then attempted to run `hg rebase` with a dirty working directory, and it still complained. The reason was that they were attempting to rebase the commit they currently had checked out, which (at least with evolve workflows enabled) involves updating the working directory to be based on the newly rebased commit. Differential Revision: https://phab.mercurial-scm.org/D6507
Mon, 10 Jun 2019 13:23:14 -0400 revlog: speed up isancestor
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 13:23:14 -0400] rev 42446
revlog: speed up isancestor Currently, it is implemented on top of commonancestorsheads. Implement it on top of reachableroots instead, as reachableroots could stop walking the graph much sooner than commonancestorsheads. Measuring repo.changelog.isancestorrev on two revisions in a private repository: before: ! wall 0.005175 comb 0.010000 user 0.010000 sys 0.000000 (best of 550) after : ! wall 0.000072 comb 0.000000 user 0.000000 sys 0.000000 (best of 36199) When hg does this kind of operations 1500 times in pull -> bookmarks.comparebookmarks -> bookmarks.validdest, that's 11s that drop from the --profile output. Differential Revision: https://phab.mercurial-scm.org/D6506
Mon, 10 Jun 2019 11:40:43 -0400 dagop: fix documentation of reachableroots
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 11:40:43 -0400] rev 42445
dagop: fix documentation of reachableroots The previous revset couldn't be correct as it is symmetric in <roots> and <heads>, but reachableroots has no such symmetry. It makes a difference with for instance reachableroots(2, 3) where 2 and 3 are both children of 1. Differential Revision: https://phab.mercurial-scm.org/D6505
Tue, 11 Jun 2019 19:52:16 +0100 phabricator: add --blocker argument to phabsend to specify blocking reviewers
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:52:16 +0100] rev 42444
phabricator: add --blocker argument to phabsend to specify blocking reviewers The way to signal to Conduit that a reviewer is considered blocking is just to wrap their PHID in "blocking()" when including it in the list of PHIDs passed to `reviewers.add`. arc doesn't have a --blocker, instead one is supposed to append a '!' to the end of reviewer names (I think reviewers are usually added in an editor rather than the command line, where '!'s can be more hazardous). moz-phab (Mozilla's arcanist wrapper) does have a --blocker argument, and being explicit like this is also more discoverable. Even `arc diff`'s help doesn't seem to mention the reviewer! syntax. Differential Revision: https://phab.mercurial-scm.org/D6512
Tue, 11 Jun 2019 19:37:19 +0100 phabricator: auto-sanitise API tokens and HTTP cookies from VCR recordings
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:37:19 +0100] rev 42443
phabricator: auto-sanitise API tokens and HTTP cookies from VCR recordings Currently when making VCR recordings one needs to manually sanitise sensitive credentials before committing and submitting them as part of tests. It is easy to imagine this being accidentally missed one time by a fallible human and said credentials being leaked. It is also possible that it wouldn't be noticed to alert the user to the leak since the recording files are so large and practically unreviewable. Thus do so automatically, so the only place that needs checking is in the test-phabricator.t file. Differential Revision: https://phab.mercurial-scm.org/D6513
Tue, 11 Jun 2019 15:46:07 +0300 py3: use .startswith() instead of bytes[0]
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 11 Jun 2019 15:46:07 +0300] rev 42442
py3: use .startswith() instead of bytes[0] Doing bytes[0] will return the ascii value of that position which breaks comparison with a bytechar. This makes test-absorb.t work again on py3. Differential Revision: https://phab.mercurial-scm.org/D6508
Sun, 09 Jun 2019 22:23:41 +0900 revset: fix merge() to fall back to changectx API if wdir specified
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:23:41 +0900] rev 42441
revset: fix merge() to fall back to changectx API if wdir specified I have a code which basically runs "0:wdir() & <user-revset>", and it crashed if merge() were passed in.
Sun, 09 Jun 2019 22:18:22 +0900 revset: use nullrev constant in merge()
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:18:22 +0900] rev 42440
revset: use nullrev constant in merge()
Fri, 31 May 2019 22:38:04 -0700 mixedrepostorecache: fix a silly redundant updating of set
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 22:38:04 -0700] rev 42439
mixedrepostorecache: fix a silly redundant updating of set Differential Revision: https://phab.mercurial-scm.org/D6470
Thu, 06 Jun 2019 18:37:21 +0200 rust-regex: fix shortcut for exact matches
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jun 2019 18:37:21 +0200] rev 42438
rust-regex: fix shortcut for exact matches The current shortcut for rootglobs that can be simplified to exact matches does not work, it instead treats the pattern as a regex, which is not the same thing. This changes fixes the behavior and introduces a test for this behavior. Differential Revision: https://phab.mercurial-scm.org/D6489
Thu, 06 Jun 2019 15:30:56 +0200 rust-filepatterns: use bytes instead of String
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jun 2019 15:30:56 +0200] rev 42437
rust-filepatterns: use bytes instead of String In my initial patch, I introduced an unnecessary hard constraint on UTF-8 filenames and patterns which I forgot to remove. Although the performance penalty for using String might be negligible, we don't want to break compatibility with non-UTF-8 encodings for no reason. Moreover, this change allows for a cleaner Rust core API. This patch introduces a new utils module that is used with this fix. Finally, PatternError was not put inside the Python module generated by Rust, which would have raised a NameError. Differential Revision: https://phab.mercurial-scm.org/D6485
Sat, 01 Jun 2019 01:24:49 +0200 doc: fix description of "predecessors" to match reality
Joerg Sonnenberger <joerg@bec.de> [Sat, 01 Jun 2019 01:24:49 +0200] rev 42436
doc: fix description of "predecessors" to match reality Differential Revision: https://phab.mercurial-scm.org/D6467
Sat, 08 Jun 2019 18:48:06 +0300 phabricator: make `hg debugcallconduit` work outside a hg repo
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:48:06 +0300] rev 42435
phabricator: make `hg debugcallconduit` work outside a hg repo I am trying to write some automations around phabricator and having debugcallconduit work outside a hg repo will be nice! Marking command as optionalrepo instead of norepo because we might to load repo/.hg/hgrc. Differential Revision: https://phab.mercurial-scm.org/D6499
Sat, 08 Jun 2019 18:41:15 +0300 phabricator: pass ui instead of repo to callconduit
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:41:15 +0300] rev 42434
phabricator: pass ui instead of repo to callconduit This will help us make `hg debugcallconduit` work outside a hg repo as next patch will mark that command as no repo. Differential Revision: https://phab.mercurial-scm.org/D6498
Sat, 08 Jun 2019 18:32:12 +0300 phabricator: pass ui into readurltoken instead of passing repo
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:32:12 +0300] rev 42433
phabricator: pass ui into readurltoken instead of passing repo The goal of this series is to make `hg debugcallconduit` work outside of a hg repo. This patch, removes requirement of repo object from readurltoken as we only need ui there. It also updates the callers to pass in ui instead of repo. Differential Revision: https://phab.mercurial-scm.org/D6497
Sat, 08 Jun 2019 19:20:31 +0300 py3: add test-contrib-emacs.t to passing tests list
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 19:20:31 +0300] rev 42432
py3: add test-contrib-emacs.t to passing tests list I installed emacs on the server running buildbot and the test started passing on Python 3. Lets add it to the list of passing test. Differential Revision: https://phab.mercurial-scm.org/D6500
Fri, 07 Jun 2019 20:19:55 +0100 phabricator: add commenting to phabsend for new/updated Diffs
Ian Moody <moz-ian@perix.co.uk> [Fri, 07 Jun 2019 20:19:55 +0100] rev 42431
phabricator: add commenting to phabsend for new/updated Diffs Especially useful when sending updates to existing Revisions so one can specify the sort of changes e.g. "Address review comments" or "Rebase to tip" If the diff content hasn't changed then it only needs a metadata update which doesn't show in the Phabricator updates UI, so don't add a comment that will. Differential Revision: https://phab.mercurial-scm.org/D6496
Wed, 05 Jun 2019 22:09:26 +0300 py3: fix test-bookmarks-corner-case.t
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:09:26 +0300] rev 42430
py3: fix test-bookmarks-corner-case.t For some reasons, the output of print was not going through. Replaced that ui.status(). Differential Revision: https://phab.mercurial-scm.org/D6481
Wed, 05 Jun 2019 22:02:57 +0300 py3: fix test-fix-metadata.t
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:02:57 +0300] rev 42429
py3: fix test-fix-metadata.t # skip-blame as just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D6480
Wed, 05 Jun 2019 22:44:38 +0300 py3: add b'' prefix at one place in run-tests.py
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:44:38 +0300] rev 42428
py3: add b'' prefix at one place in run-tests.py #skip-blame because just b'' prefix Differential Revision: https://phab.mercurial-scm.org/D6482
Thu, 06 Jun 2019 10:07:14 -0700 copies: separate added/removed files by newline instead of null
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jun 2019 10:07:14 -0700] rev 42427
copies: separate added/removed files by newline instead of null This makes it more consistent with how we encode copies (newline-separated lists of null-separated pairs). This perhaps makes {extras} a little less readable (?) despite avoiding the escaping. I don't know how I feel about this patch. I'm okay with it being queued or dropped. Differential Revision: https://phab.mercurial-scm.org/D6486
Wed, 22 May 2019 09:54:00 -0700 copies: also encode p[12]copies destination as index into "files" list
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 May 2019 09:54:00 -0700] rev 42426
copies: also encode p[12]copies destination as index into "files" list This is mostly for consistency with the filesaddes/filesremoved fields, but it should also save a bit of space. Differential Revision: https://phab.mercurial-scm.org/D6431
Wed, 05 Jun 2019 11:23:25 +0200 discovery: be more conservative when adjusting the sample size
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 11:23:25 +0200] rev 42425
discovery: be more conservative when adjusting the sample size Since 5b34972a0094, the discovery will increase the sample size when it detect a "complex" undecided set. However this detection focussed on the number of roots only, this could regress discovery performance when the undecided set has many roots that eventually get merged into a few heads. To prevent such misbehavior, we adjust the logic to take in account both heads and roots. The sample size will be increased only if both are especially large. Performance testing on the same case as 5b34972a0094, does not show a significant difference.
Thu, 16 May 2019 16:22:20 +0200 rust-dirstate: create dirstate submodule
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 May 2019 16:22:20 +0200] rev 42424
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
Wed, 05 Jun 2019 12:51:21 -0400 profiling: show actual time spent in hotpath display
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 05 Jun 2019 12:51:21 -0400] rev 42423
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
Wed, 05 Jun 2019 14:29:44 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 05 Jun 2019 14:29:44 -0700] rev 42422
merge with stable
Fri, 31 May 2019 22:37:14 -0700 bookmarks: use correct store for "ambiguity check" stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 22:37:14 -0700] rev 42421
bookmarks: use correct store for "ambiguity check" I still don't quite know what the check does, but I clearly got it wrong in 526750cdd02d (bookmarks: keep bookmarks in .hg/store if new config set, 2019-05-15). Just compare with the strings we use in @repofilecache and @storecache. These bugs were then copied to the stable branch in c2b83c957621 (localrepo: grab mixedrepostorecache class from 526750cdd02d, 2019-05-20) and 2338bdea4474 (bookmark: also make bookmark cache depends of the changelog, 2019-05-20). As a result, test-wireproto-exchangev2.t is flaky on both branches. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6469
Wed, 05 Jun 2019 10:18:00 -0400 merge with stable
Augie Fackler <augie@google.com> [Wed, 05 Jun 2019 10:18:00 -0400] rev 42420
merge with stable
Tue, 04 Jun 2019 21:13:35 +0900 root: add template variables pointing to repository directories
Yuya Nishihara <yuya@tcha.org> [Tue, 04 Jun 2019 21:13:35 +0900] rev 42419
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.
Tue, 04 Jun 2019 20:58:39 +0900 root: add support for -Tformatter option
Yuya Nishihara <yuya@tcha.org> [Tue, 04 Jun 2019 20:58:39 +0900] rev 42418
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.
Thu, 23 May 2019 03:03:36 +0530 narrow: pass the bundle to bundle2.widen_bundle() instead of generating there
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 23 May 2019 03:03:36 +0530] rev 42417
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
Thu, 23 May 2019 02:48:25 +0530 narrow: refactor code around widening complicated by previous patch
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 23 May 2019 02:48:25 +0530] rev 42416
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
(0) -30000 -10000 -3000 -1000 -240 +240 +1000 +3000 tip