Joerg Sonnenberger <joerg@bec.de> [Thu, 23 Jul 2020 20:23:44 +0200] rev 45474
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 45473
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 45472
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 45471
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 45470
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 45469
merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:52:24 +0900] rev 45468
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 45467
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 45466
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 45465
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 45464
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."
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Sep 2020 11:18:12 -0700] rev 45463
resourceutil: document when we expect to take the importlib.resouces code path
Differential Revision: https://phab.mercurial-scm.org/D9018
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 22:00:00 -0700] rev 45462
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:35:49 -0700] rev 45461
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:55:08 -0700] rev 45460
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 13:12:34 -0700] rev 45459
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
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 26 Aug 2020 17:24:22 +0530] rev 45458
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
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 14:45:16 +0530] rev 45457
debugmergestate: sort extras before printing
Prevents flaky output.
Differential Revision: https://phab.mercurial-scm.org/D8986
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 24 Aug 2020 18:59:19 +0530] rev 45456
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
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Sep 2020 16:51:40 +0530] rev 45455
tests: update lockdelay.py to handle the `wait` argument
Spotted by a future change.
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 14:14:04 +0530] rev 45454
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Fri, 11 Sep 2020 13:04:05 +0530] rev 45453
py3: fix bytes and str mixup in run-tests
Differential Revision: https://phab.mercurial-scm.org/D9009
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 17 Aug 2020 10:59:30 +0200] rev 45452
hg-core: fix some `clippy` warnings
Differential Revision: https://phab.mercurial-scm.org/D8957
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 17 Aug 2020 16:55:43 +0200] rev 45451
rhg: print error message when argument parsing fails
Differential Revision: https://phab.mercurial-scm.org/D8956
Antoine Cezar <antoine.cezar@octobus.net> [Thu, 13 Aug 2020 16:36:42 +0200] rev 45450
rhg: fix `clippy` warnings
Differential Revision: https://phab.mercurial-scm.org/D8955
Antoine Cezar <antoine.cezar@octobus.net> [Tue, 04 Aug 2020 16:11:23 +0200] rev 45449
rhg: pass `ui` to `Command` `run`
Allow implementation of `From<clap::ArgMatches> for Command`
Differential Revision: https://phab.mercurial-scm.org/D8954
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 03 Aug 2020 11:55:59 +0200] rev 45448
rhg: add harness tests for rhg files
Differential Revision: https://phab.mercurial-scm.org/D8873
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jul 2020 16:55:44 +0200] rev 45447
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
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 08 Sep 2020 19:36:40 +0530] rev 45446
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
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Sep 2020 13:37:35 +0530] rev 45445
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.