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.
Sun, 13 Sep 2020 18:14:51 +0900 test-simple-update: add test for -d DATE option
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.
Sun, 13 Sep 2020 17:46:48 +0900 largefiles: walk history in ascending order while downloading all lfiles
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
Sun, 13 Sep 2020 17:43:19 +0900 largefiles: replace use of walkchangerevs() with simple revset query
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.
Fri, 11 Sep 2020 10:47:17 +0900 largefiles: remove unused 'rev' parameter from downloadlfiles()
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."
Sat, 12 Sep 2020 11:18:12 -0700 resourceutil: document when we expect to take the importlib.resouces code path
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
Thu, 10 Sep 2020 22:00:00 -0700 templater: fix reading of templates in frozen binaries with py3 < 3.7
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
Fri, 11 Sep 2020 09:35:49 -0700 histedit: cache description line
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
Fri, 11 Sep 2020 09:55:08 -0700 tests: make emacs test less strict
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
Thu, 10 Sep 2020 13:12:34 -0700 graphlog: use '%' only if there are *unresolved* conflicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 13:12:34 -0700] rev 45448
graphlog: use '%' only if there are *unresolved* conflicts In 14d0e89520a2, I made graphlog use '%' for the "other" context when there's an existing merge state. However, that has confused many people because it shows up even if all conflicts are already resolved, which makes it show up even after e.g. `hg update -m` with automatically resolved conflicts. This patch makes it so we show the '%' only if there still unresolved conflicts. This patch replaces my earlier attempt in D8930, where I decided to automatically clear the mergestate if there are no remaining conflicts. That had the problem that it wouldn't let the user re-resolve the conflicts using `hg resolve`. Note that an in-progress "proper" merge (one that will result in a commit with two parents, such as after `hg merge`) will already have two dirstate parents before the commit happens. That means that both sides of the merge will get drawn as '@' in the graph, since "is dirstate parent" takes precedence over "is involved in merge conflict". Differential Revision: https://phab.mercurial-scm.org/D9007
Wed, 26 Aug 2020 17:24:22 +0530 merge: show number of ancestors in bid merge debug notes
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 26 Aug 2020 17:24:22 +0530] rev 45447
merge: show number of ancestors in bid merge debug notes A good number of times, we don't generate an action for a file in manifestmerge() which can result in bid merge doing the wrong thing. Mentioning the number of ancestors from which we are bidding will help spot such cases where we are not returning an action. Differential Revision: https://phab.mercurial-scm.org/D8967
Thu, 03 Sep 2020 14:45:16 +0530 debugmergestate: sort extras before printing
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 14:45:16 +0530] rev 45446
debugmergestate: sort extras before printing Prevents flaky output. Differential Revision: https://phab.mercurial-scm.org/D8986
Mon, 24 Aug 2020 18:59:19 +0530 debugmergestate: show extras for files which are not in mergestate
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 24 Aug 2020 18:59:19 +0530] rev 45445
debugmergestate: show extras for files which are not in mergestate With recent changes and future changes, we will like to store extras information about files which were merged automatically. Hence, we will have merge extras for files which are not in the mergestate. Differential Revision: https://phab.mercurial-scm.org/D8942
Thu, 10 Sep 2020 16:51:40 +0530 tests: update lockdelay.py to handle the `wait` argument
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Sep 2020 16:51:40 +0530] rev 45444
tests: update lockdelay.py to handle the `wait` argument Spotted by a future change.
Thu, 03 Sep 2020 14:14:04 +0530 commit: pass mergestate into _filecommit() instead of re-reading it
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 14:14:04 +0530] rev 45443
commit: pass mergestate into _filecommit() instead of re-reading it mergestate reading although cheap is not free. Let's read mergestate once on top and pass it into `_filecommit()`. In upcoming patches, we will be reading mergestate more in `_filecommit()`. Differential Revision: https://phab.mercurial-scm.org/D8984
Fri, 11 Sep 2020 13:04:05 +0530 py3: fix bytes and str mixup in run-tests
Sushil khanchi <sushilkhanchi97@gmail.com> [Fri, 11 Sep 2020 13:04:05 +0530] rev 45442
py3: fix bytes and str mixup in run-tests Differential Revision: https://phab.mercurial-scm.org/D9009
Mon, 17 Aug 2020 10:59:30 +0200 hg-core: fix some `clippy` warnings
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 17 Aug 2020 10:59:30 +0200] rev 45441
hg-core: fix some `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8957
Mon, 17 Aug 2020 16:55:43 +0200 rhg: print error message when argument parsing fails
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 17 Aug 2020 16:55:43 +0200] rev 45440
rhg: print error message when argument parsing fails Differential Revision: https://phab.mercurial-scm.org/D8956
Thu, 13 Aug 2020 16:36:42 +0200 rhg: fix `clippy` warnings
Antoine Cezar <antoine.cezar@octobus.net> [Thu, 13 Aug 2020 16:36:42 +0200] rev 45439
rhg: fix `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8955
Tue, 04 Aug 2020 16:11:23 +0200 rhg: pass `ui` to `Command` `run`
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 04 Aug 2020 16:11:23 +0200] rev 45438
rhg: pass `ui` to `Command` `run` Allow implementation of `From<clap::ArgMatches> for Command` Differential Revision: https://phab.mercurial-scm.org/D8954
Mon, 03 Aug 2020 11:55:59 +0200 rhg: add harness tests for rhg files
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 03 Aug 2020 11:55:59 +0200] rev 45437
rhg: add harness tests for rhg files Differential Revision: https://phab.mercurial-scm.org/D8873
Thu, 30 Jul 2020 16:55:44 +0200 rhg: make output of `files` relative to the current directory and the root
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jul 2020 16:55:44 +0200] rev 45436
rhg: make output of `files` relative to the current directory and the root This matches the behavior of `hg files`. The util is added in `hg-core` instead of `rhg` because this operation could be useful for other external tools. (this was definitely not prompted by rust issue #50784, I swear) Differential Revision: https://phab.mercurial-scm.org/D8872
Tue, 08 Sep 2020 19:36:40 +0530 tags: take lock instead of wlock before writing hgtagsfnodes1 cache
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 08 Sep 2020 19:36:40 +0530] rev 45435
tags: take lock instead of wlock before writing hgtagsfnodes1 cache This cache is shared across stores and hence we should take store lock before writing to it. Otherwise there will be race where one share with wlock is writing to this cache and other share with wlock is trying to read it simultaneously. Differential Revision: https://phab.mercurial-scm.org/D9001
Thu, 10 Sep 2020 13:37:35 +0530 statichttprepo: use LockUnavailable() instead of Abort() for lock (API)
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Sep 2020 13:37:35 +0530] rev 45434
statichttprepo: use LockUnavailable() instead of Abort() for lock (API) If we try to get a lock on statichttprepo, we get `error.Abort()` instead of subclass of `error.LockError()`. The callers which catches `error.LockError` fails to catch this case as the correct error is not raised. Raising `error.LockUnavaible()` is same as what is done for wlock also.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip