Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 14 Sep 2020 11:32:24 -0400] rev 45462
fsmonitor: increase the threshold before we recommend it, when using rust
50k files works just fine with the rust status, and it's annoying to
get told "consider using fsmonitor" when we have another solution to
the status speed.
400k files was not chosen in any rigorous way. I know 200k files is
fine. Twice as many files should still be fine.
Differential Revision: https://phab.mercurial-scm.org/D9021
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 06:15:06 +0200] rev 45461
copy-tracing: test case where a merge reverted a file deletion
This case is currently broken for commit centric copy tracing. So we add an
official case for it with a note about it being broken.
Fixing it will requires multiples change in code related to merge, commit and
copy tracing, so we introduce it beforehand for simplicity.
Also, I have been sitting on this test for 3 months so I would rather have it
upstream.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 06:04:48 +0200] rev 45460
copy-tracing: test case where we go across a changed/deleted merge
This case is currently broken in the commit centric case. So we add an official
case for it with a note about it being broken.
Fixing it will requires multiples change in code related to merge, commit and
copy tracing, so we introduce it beforehand for simplicity.
Also, I have been sitting on this test for 3 months so I would rather have it
upstream.
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 26 Aug 2020 17:20:53 +0530] rev 45459
merge: show list of bids for each file in bid-merge in ui.debug()
Earlier, we were showing the list of bids only when we were ambiguously picking.
However, the cases where we unambiguously picked a side may not always be
correct and need to be fixed.
Having list of bids for all files will be helpful in debugging.
Differential Revision: https://phab.mercurial-scm.org/D8966
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Sep 2020 19:39:51 +0900] rev 45458
merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:52:24 +0900] rev 45457
cmdutil: reimplement finddate() without using walkchangerevs()
It's simpler and slightly faster maybe because a fewer Python ops would
run.
Unscientific benchmark:
$ python -m timeit \
-s 'from mercurial import hg, ui, cmdutil; repo = hg.repository(ui.ui())' \
'cmdutil.finddate(repo.ui, repo, "<2008-01-01")'
(orig) 10 loops, best of 3: 1.45 sec per loop
(new) 10 loops, best of 3: 1.25 sec per loop
Now "hg churn" and "hg grep" are the only users of walkchangerevs(), which
I want to refactor and fix bugs.
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 18:14:51 +0900] rev 45456
test-simple-update: add test for -d DATE option
I couldn't find any tests for cmdutil.finddate() except for the abort case.
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:46:48 +0900] rev 45455
largefiles: walk history in ascending order while downloading all lfiles
I don't think the order matters. Maybe it's purely because of the use of
walkchangerevs(), which was originally designed for "hg log" command.
Surprisingly, the number of objects fetched in test-largefiles.t has changed.
According to the --verbose output, the order of the following fetches flipped
and the latter got deduplicated.
getting large3:
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
found
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
getting sub/large4:
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
found
eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:43:19 +0900] rev 45454
largefiles: replace use of walkchangerevs() with simple revset query
Since it does nothing in prepare(), what we're doing is just walking
revisions matching ".hglf" in reverse order.
Yuya Nishihara <yuya@tcha.org> [Fri, 11 Sep 2020 10:47:17 +0900] rev 45453
largefiles: remove unused 'rev' parameter from downloadlfiles()
It's no longer used since
83ead8cb0ff2 "largefiles: implement pull
--all-largefiles as a special case of --lfrev."
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Sep 2020 11:18:12 -0700] rev 45452
resourceutil: document when we expect to take the importlib.resouces code path
Differential Revision: https://phab.mercurial-scm.org/D9018
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 22:00:00 -0700] rev 45451
templater: fix reading of templates in frozen binaries with py3 < 3.7
When using a frozen binary with py3 < 3.7, there's no
`importlib.resources` module, so we use the code path that reads the
resources from the file system. That code path expects bytes for
package name and resource name.
Differential Revision: https://phab.mercurial-scm.org/D9008
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:35:49 -0700] rev 45450
histedit: cache description line
Navigating the curses-based histedit interface can be pretty slow
because it redraws everything whenever you make a change.
This patch simply replaces `@property` by `@util.propertycache` on the
`histeditrule.desc()` function so it's not re-calculated every time
the screen needs to be re-rendered. I timed it on an example of 30
simple commits, where I moved the top commit down 25 steps and then up
25 steps after. Before this patch, that (the whole `hg histedit`
invocation) took 11.6 s of CPU and after this patch it took 0.8 s).
Differential Revision: https://phab.mercurial-scm.org/D9016
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:55:08 -0700] rev 45449
tests: make emacs test less strict
It was failing like this for me:
```
@@ -2,7 +2,7 @@
$ emacs -q -no-site-file -batch -l $TESTDIR/../contrib/hg-test-mode.el \
> -f ert-run-tests-batch-and-exit
Running 1 tests (*) (glob)
- passed 1/1 hg-test-mode--compilation-mode-support
+ passed 1/1 hg-test-mode--compilation-mode-support (0.045732 sec)
- Ran 1 tests, 1 results as expected (*) (glob)
+ Ran 1 tests, 1 results as expected, 0 unexpected (2020-09-11 16:49:56+0000, 0.046034 sec)
```
Differential Revision: https://phab.mercurial-scm.org/D9017