Fri, 11 Sep 2020 15:52:06 -0700 repo: avoid copying/updating a dict on every `repo.__getitem__`
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
Thu, 23 Jul 2020 20:23:44 +0200 obsstore: refactor v1 logic to fix 32 byte hash support
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
Mon, 14 Sep 2020 11:32:24 -0400 fsmonitor: increase the threshold before we recommend it, when using rust
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
Fri, 19 Jun 2020 06:15:06 +0200 copy-tracing: test case where a merge reverted a file deletion
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.
Fri, 19 Jun 2020 06:04:48 +0200 copy-tracing: test case where we go across a changed/deleted merge
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.
Wed, 26 Aug 2020 17:20:53 +0530 merge: show list of bids for each file in bid-merge in ui.debug()
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
Mon, 14 Sep 2020 19:39:51 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Sep 2020 19:39:51 +0900] rev 45458
merge with stable
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip