Wed, 11 Mar 2020 17:42:56 +0100 test-install: don't print Rust re2 bindings information if Rust is not in use
Raphaël Gomès <rgomes@octobus.net> [Wed, 11 Mar 2020 17:42:56 +0100] rev 44547
test-install: don't print Rust re2 bindings information if Rust is not in use Differential Revision: https://phab.mercurial-scm.org/D8273
Mon, 09 Mar 2020 21:35:36 -0400 tests: drop an extraneous (glob) from test-debugbackupbundle.t
Matt Harbison <matt_harbison@yahoo.com> [Mon, 09 Mar 2020 21:35:36 -0400] rev 44546
tests: drop an extraneous (glob) from test-debugbackupbundle.t Since this was not needed, it ends up causing the test to end with an error saying that the output changed, but with no diff and a message at the end saying "no result code from test". Differential Revision: https://phab.mercurial-scm.org/D8269
Sat, 29 Feb 2020 12:58:38 +0530 pull: add `--confirm` flag to confirm before writing changes
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Feb 2020 12:58:38 +0530] rev 44545
pull: add `--confirm` flag to confirm before writing changes This introduces a new flag to pull command `--confirm` and also a config option named `pull.confirm` which if used will prompt user describing changes which are pulled and asking whether to accept them or not. Differential Revision: https://phab.mercurial-scm.org/D8200
Sat, 29 Feb 2020 12:58:13 +0530 scmutil: add option to register summary callbacks as transaction validators
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Feb 2020 12:58:13 +0530] rev 44544
scmutil: add option to register summary callbacks as transaction validators We have a list of summary callbacks which are run after the transaction is closed to show what has changed and what not. This patch makes it possible to register those callbacks as transaction validators so that we can show summary before committing the transaction and prompt user to accept the changes. The goal of this is to implement `pull --confirm`. Differential Revision: https://phab.mercurial-scm.org/D8199
Sat, 29 Feb 2020 12:56:37 +0530 transaction: add functionality to have multiple validators
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 29 Feb 2020 12:56:37 +0530] rev 44543
transaction: add functionality to have multiple validators This will help us in adding more validators which can aggregate data from transaction and prompt user whether to commit the transaction or not. The current target is to use this to implement `pull --confirm`. Differential Revision: https://phab.mercurial-scm.org/D8198
Wed, 04 Mar 2020 22:13:15 +0530 hgit: make sure repository is local before checking for store type
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 04 Mar 2020 22:13:15 +0530] rev 44542
hgit: make sure repository is local before checking for store type httppeer (and maybe others too) does not have a store attribute. This was causing `hg pull` being broken on a hg repository when the extension is enabled. localpeer.local() does returns a non-None value but I am not sure if it matters. Differential Revision: https://phab.mercurial-scm.org/D8217
Fri, 06 Mar 2020 18:08:23 +0100 hg-core: add function timing information
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 18:08:23 +0100] rev 44541
hg-core: add function timing information This change makes use of the newly added logging infrastructure to trace the execution time of some important calls. This approach is very much complementary to using a profiler and will not guard against out-of-order execution or other kinds of compiler optimizations. That said, it is useful to get a rough high-level idea of where time is spent. Differential Revision: https://phab.mercurial-scm.org/D8253
Fri, 06 Mar 2020 18:08:13 +0100 rust: add logging utils
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 18:08:13 +0100] rev 44540
rust: add logging utils This change adds the `log` crate, the community-approved logging facade backed by Rust core developers as well as the logging-consumer crate `simple_logger` to build a foundation for logging from Rust. Using this setup allows us to choose how to log depending on the way `hg-core` is used: if it's within the context of `hg-cpython`, we might not want to use it the same way as with a direct cli for example. Differential Revision: https://phab.mercurial-scm.org/D8252
Fri, 06 Mar 2020 17:51:24 +0100 rust-status: traverse working directory in parallel
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 17:51:24 +0100] rev 44539
rust-status: traverse working directory in parallel Using `rayon` for this task ensures that we are using the same work-stealing threadpool for everything. This change introduces `crossbeam` as an explicit dependency, although it is already a dependency of `rayon`. It provides better structures for multi-threaded tasks than the stdlib. Differential Revision: https://phab.mercurial-scm.org/D8251
Fri, 06 Mar 2020 17:51:03 +0100 rust-status: wrap `stat_dmap_entries` to ease profiling
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 17:51:03 +0100] rev 44538
rust-status: wrap `stat_dmap_entries` to ease profiling Differential Revision: https://phab.mercurial-scm.org/D8250
Fri, 06 Mar 2020 17:48:30 +0100 rust-status: refactor handling of unknown files
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 17:48:30 +0100] rev 44537
rust-status: refactor handling of unknown files Differential Revision: https://phab.mercurial-scm.org/D8249
Wed, 19 Feb 2020 11:14:30 +0100 rust-status: move to recursive traversal to prepare for parallel traversal
Raphaël Gomès <rgomes@octobus.net> [Wed, 19 Feb 2020 11:14:30 +0100] rev 44536
rust-status: move to recursive traversal to prepare for parallel traversal I have looked into traversing the working directory in parallel either by a recursive or an iterative algorithm. The recursive approach won quite decisively both in terms of performance and code readability. You can look at my experiment here: https://heptapod.octobus.net/Alphare/rayon-recursive-traversal The chance of a stack overflow happening because the directories get too nested seems slim. This change does not yet do anything in parallel. Differential Revision: https://phab.mercurial-scm.org/D8215
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 tip