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."