Kyle Lippincott <spectral@google.com> [Fri, 11 Sep 2020 15:52:06 -0700] rev 45464
repo: avoid copying/updating a dict on every `repo.__getitem__`
This has some mild performance benefits. I'm looking into a pathological case
where one of our `hg log` invocations takes several seconds, and according to
hyperfine this reduces the wall time of the entire operation (running in chg)
from:
```
Time (mean ± σ): 7.390 s ± 0.106 s [User: 7.058 s, System: 0.271 s]
Range (min … max): 7.300 s … 7.625 s
```
to:
```
Time (mean ± σ): 7.046 s ± 0.091 s [User: 6.714 s, System: 0.279 s]
Range (min … max): 6.916 s … 7.169 s
```
Note: the log command is slow due to an issue in our custom stuff executing
`repo[<arg>]` 298,800 times. This performance improvement is likely not
noticeable during normal operation, but I don't feel like it's making the code
more difficult to understand, and every small bit helps.
Differential Revision: https://phab.mercurial-scm.org/D9022
Joerg Sonnenberger <joerg@bec.de> [Thu, 23 Jul 2020 20:23:44 +0200] rev 45463
obsstore: refactor v1 logic to fix 32 byte hash support
Refactor the v1 logic to determine the node parsing based on the flag.
Move the predecessor out of the fixed part and handle it like the other
nodes, removing most of the duplicated code for parsing 20/32 bytes
hashes.
Differential Revision: https://phab.mercurial-scm.org/D8801
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