Mon, 14 Sep 2020 13:51:39 +0530 mergeresult: introduce dedicated tuple for no-op actions
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 13:51:39 +0530] rev 45466
mergeresult: introduce dedicated tuple for no-op actions This will help us in adding more no-op actions in next patch while keeping the code cleaner.
Fri, 19 Jun 2020 13:27:46 +0200 tests: add criss cross merging tests whose behavior need to be fixed
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 13:27:46 +0200] rev 45465
tests: add criss cross merging tests whose behavior need to be fixed Merging two changesets can mark a file as removed post merge. However, in some cases, a user might not want to remove that file and they revert the removal back and commit the merge. All this works perfectly well. However, when we do criss-cross merges with such merge where user explicitly choose to revert the removal with one where another user choose the removal, we does not get any conflict. The intent here is conflicting and merge should result in conflicts. One user merged and want to keep the file while other user merged and want to remove the file. Merging those merges should result in conflicts. This patch adds test cases for these cases. Differential Revision: https://phab.mercurial-scm.org/D8939
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
Sun, 13 Sep 2020 17:52:24 +0900 cmdutil: reimplement finddate() without using walkchangerevs()
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip