Thu, 26 Dec 2019 14:02:50 -0800 copy: move argument validation a little earlier
Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Dec 2019 14:02:50 -0800] rev 44400
copy: move argument validation a little earlier Argument validation is usually done early and I will want it done before some code that I'm about to add. Differential Revision: https://phab.mercurial-scm.org/D8033
Tue, 28 Jan 2020 14:07:57 -0800 copy: add experimetal support for unmarking committed copies
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:07:57 -0800] rev 44399
copy: add experimetal support for unmarking committed copies The simplest way I'm aware of to unmark a file as copied after committing is this: hg uncommit --keep <dest> hg forget <dest> hg add <dest> hg amend This patch teaches `hg copy --forget` a `-r` argument to simplify that into: hg copy --forget --at-rev . <dest> In addition to being simpler, it doesn't touch the working copy, so it can easily be used even if the destination file has been modified in the working copy. I'll teach `hg copy` without `--forget` to work with `--at-rev` next. Differential Revision: https://phab.mercurial-scm.org/D8030
Fri, 20 Dec 2019 15:50:13 -0800 copy: add option to unmark file as copied
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 15:50:13 -0800] rev 44398
copy: add option to unmark file as copied To unmark a file as copied, the user currently has to do this: hg forget <dest> hg add <dest> The new command simplifies that to: hg copy --forget <dest> That's not a very big improvement, but I'm planning to also teach `hg copy [--forget]` a `--at-rev` argument for marking/unmarking copies after commit (usually with `--at-rev .`). Differential Revision: https://phab.mercurial-scm.org/D8029
Tue, 11 Feb 2020 11:18:52 +0100 nodemap: introduce an option to use mmap to read the nodemap mapping
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Feb 2020 11:18:52 +0100] rev 44397
nodemap: introduce an option to use mmap to read the nodemap mapping The performance and memory benefit is much greater if we don't have to copy all the data in memory for each information. So we introduce an option (on by default) to read the data using mmap. This changeset is the last one definition the API for index support nodemap data. (they have to be able to use the mmaping). Below are some benchmark comparing the best we currently have in 5.3 with the final step of this series (using the persistent nodemap implementation in Rust). The benchmark run `hg perfindex` with various revset and the following variants: Before: * do not use the persistent nodemap * use the CPython implementation of the index for nodemap * use mmapping of the changelog index After: * use the MixedIndex Rust code, with the NodeTree object for nodemap access (still in review) * use the persistent nodemap data from disk * access the persistent nodemap data through mmap * use mmapping of the changelog index The persistent nodemap greatly speed up most operation on very large repositories. Some of the previously very fast lookup end up a bit slower because the persistent nodemap has to be setup. However the absolute slowdown is very small and won't matters in the big picture. Here are some numbers (in seconds) for the reference copy of mozilla-try: Revset Before After abs-change speedup -10000: 0.004622 0.005532 0.000910 × 0.83 -10: 0.000050 0.000132 0.000082 × 0.37 tip 0.000052 0.000085 0.000033 × 0.61 0 + (-10000:) 0.028222 0.005337 -0.022885 × 5.29 0 0.023521 0.000084 -0.023437 × 280.01 (-10000:) + 0 0.235539 0.005308 -0.230231 × 44.37 (-10:) + :9 0.232883 0.000180 -0.232703 ×1293.79 (-10000:) + (:99) 0.238735 0.005358 -0.233377 × 44.55 :99 + (-10000:) 0.317942 0.005593 -0.312349 × 56.84 :9 + (-10:) 0.313372 0.000179 -0.313193 ×1750.68 :9 0.316450 0.000143 -0.316307 ×2212.93 On smaller repositories, the cost of nodemap related operation is not as big, so the win is much more modest. Yet it helps shaving a handful of millisecond here and there. Here are some numbers (in seconds) for the reference copy of mercurial: Revset Before After abs-change speedup -10: 0.000065 0.000097 0.000032 × 0.67 tip 0.000063 0.000078 0.000015 × 0.80 0 0.000561 0.000079 -0.000482 × 7.10 -10000: 0.004609 0.003648 -0.000961 × 1.26 0 + (-10000:) 0.005023 0.003715 -0.001307 × 1.35 (-10:) + :9 0.002187 0.000108 -0.002079 ×20.25 (-10000:) + 0 0.006252 0.003716 -0.002536 × 1.68 (-10000:) + (:99) 0.006367 0.003707 -0.002660 × 1.71 :9 + (-10:) 0.003846 0.000110 -0.003736 ×34.96 :9 0.003854 0.000099 -0.003755 ×38.92 :99 + (-10000:) 0.007644 0.003778 -0.003866 × 2.02 Differential Revision: https://phab.mercurial-scm.org/D7894
Fri, 14 Feb 2020 15:03:26 +0100 rust-dirstatemap: directly return `non_normal` and `other_entries`
Raphaël Gomès <rgomes@octobus.net> [Fri, 14 Feb 2020 15:03:26 +0100] rev 44396
rust-dirstatemap: directly return `non_normal` and `other_entries` This cleans up the interface which I previously thought needed to be uglier than in reality. No performance difference, simple refactoring. Differential Revision: https://phab.mercurial-scm.org/D8121
Thu, 26 Dec 2019 14:12:45 -0800 copy: rename `wctx` to `ctx` since it will not necessarily be working copy
Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Dec 2019 14:12:45 -0800] rev 44395
copy: rename `wctx` to `ctx` since it will not necessarily be working copy Differential Revision: https://phab.mercurial-scm.org/D8032
Fri, 20 Dec 2019 14:03:12 -0800 copy: rewrite walkpat() to depend less on dirstate
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 14:03:12 -0800] rev 44394
copy: rewrite walkpat() to depend less on dirstate I want to add a `hg cp/mv -r <rev>` option to mark files as copied/moved in an existing commit (amending that commit). The code needs to not depend on the dirstate for that. Differential Revision: https://phab.mercurial-scm.org/D8031
Thu, 13 Feb 2020 10:12:12 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 10:12:12 -0800] rev 44393
merge with stable
Sat, 01 Feb 2020 12:57:32 +0900 pathutil: resurrect comment about path auditing order
Yuya Nishihara <yuya@tcha.org> [Sat, 01 Feb 2020 12:57:32 +0900] rev 44392
pathutil: resurrect comment about path auditing order It was removed at 51c86c6167c1, but expensive symlink traversal isn't the only reason we should walk path components from the root.
Wed, 16 Oct 2019 14:12:48 +0200 rust-dirstatemap: remove additional lookup in dirstate.matches
Raphaël Gomès <rgomes@octobus.net> [Wed, 16 Oct 2019 14:12:48 +0200] rev 44391
rust-dirstatemap: remove additional lookup in dirstate.matches We use the same trick as the Python implementation Differential Revision: https://phab.mercurial-scm.org/D7119
Tue, 31 Dec 2019 12:43:57 +0100 rust-nodemap: insert method
Georges Racinet <georges.racinet@octobus.net> [Tue, 31 Dec 2019 12:43:57 +0100] rev 44390
rust-nodemap: insert method In this implementation, we are in direct competition with the C version: this Rust version will have a clear startup advantage because it will read the data from disk, but the insertion happens all in memory for both. Differential Revision: https://phab.mercurial-scm.org/D7795
Wed, 22 Jan 2020 14:21:34 -0500 recover: don't verify by default
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 22 Jan 2020 14:21:34 -0500] rev 44389
recover: don't verify by default The reason is: - it's not that hard to trigger interrupted transactions: just run out of disk space - it takes forever to verify on large repos. Before --no-verify, I told people to C-c hg recover when the progress bar showed up. Now I tell them to pass --no-verify. - I don't remember a single case where the verification step was useful This is technically a change of behavior. Perhaps this would be better suited for tweakdefaults? Differential Revision: https://phab.mercurial-scm.org/D7972
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 tip