Wed, 23 Sep 2020 15:15:46 +0200 sidedata: simply read added files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:15:46 +0200] rev 45575
sidedata: simply read added files from the `ChangingFiles` object
Wed, 23 Sep 2020 15:13:44 +0200 sidedata: add a `decode_files_sidedata` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:13:44 +0200] rev 45574
sidedata: add a `decode_files_sidedata` function Right now the function mostly gather existing code to build a consistent object. However having this function allow us prepare all user code independently from the actual side data format change (and associated encoding/decoding changes) Strictly speaking, we could not need to passe the sidedata explicitly since we have access to it though the `changelogrevision` object. However, the short term goal is to drop that first parameter to only pass the sidedata binaries.
Tue, 15 Sep 2020 15:37:32 +0200 changelog: add a `changes` property on `changelogrevision`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Sep 2020 15:37:32 +0200] rev 45573
changelog: add a `changes` property on `changelogrevision` For the sidedata storage we are moving toward "all in one" block containing the equivalent of a "ChangingFiles" instance. We do various refactoring beforehand to prepare the usage of theses new data in the code. Since the object use slots, the "property cache" tricks cannot be used, and we cache the value manually.
Tue, 22 Sep 2020 10:27:35 +0200 sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 22 Sep 2020 10:27:35 +0200] rev 45572
sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata` We are storing more than copies information, so lets make it clear.
Sat, 12 Sep 2020 21:45:37 +0900 log: pass around --rev option by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:45:37 +0900] rev 45571
log: pass around --rev option by walkopts
Sat, 12 Sep 2020 21:39:58 +0900 log: parse --limit option by logcmdutil.parseopts()
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:39:58 +0900] rev 45570
log: parse --limit option by logcmdutil.parseopts()
Sat, 12 Sep 2020 21:35:26 +0900 log: pass around --follow/--follow-first options by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:35:26 +0900] rev 45569
log: pass around --follow/--follow-first options by walkopts
Sat, 12 Sep 2020 21:06:16 +0900 log: introduce struct that carries log traversal options
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:06:16 +0900] rev 45568
log: introduce struct that carries log traversal options I tried to refactor logcmdutil.getrevs() without using an options struct, but none of these attempts didn't work out. Since every stage of getrevs() needs various log command options (e.g. both matcher and revset query need file patterns), it isn't possible to cleanly split getrevs() into a command layer and a core logic. So, this patch introduces a named struct to carry command options in slightly abstracted way, which will be later used by "hg grep" and "hg churn". More fields will be added to the walkopt struct. Type hints aren't verified. I couldn't figure out how to teach pytype to load its own attr type stubs in place of our .thirdparty.attr. Conditional import didn't work. s/^from \.thirdparty // is the only way I found pytype could parse the @attr.ib decorator.
Sat, 12 Sep 2020 16:19:01 +0900 log: remove unused argument from _makerevset()
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 16:19:01 +0900] rev 45567
log: remove unused argument from _makerevset() I want to make getrevs() reusable for other commands, but the dependency graph of this getrevs() function is a mess. Let's minimize it first.
Sat, 12 Sep 2020 16:11:10 +0900 log: remove stale comment about order of user revset
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 16:11:10 +0900] rev 45566
log: remove stale comment about order of user revset _makerevset() no longer depends on the computed revs since ea3320015d54 "log: remove dead code to follow descendants if ascending revisions specified."
Fri, 25 Sep 2020 17:51:34 +0200 rust: add `dirstate_tree` module
Raphaël Gomès <rgomes@octobus.net> [Fri, 25 Sep 2020 17:51:34 +0200] rev 45565
rust: add `dirstate_tree` module Mercurial needs to represent the filesystem hierarchy on which it operates, for example in the dirstate. Its current on-disk representation is an unsorted, flat structure that gets transformed in the current Rust code into a `HashMap`. This loses the hierarchical information of the dirstate, leading to some unfortunate performance and algorithmic compromises. This module adds an implementation of a radix tree that is specialized for representing the dirstate: its unit is the path component. I have made no efforts to optimize either its memory footprint or its insertion speed: they're pretty bad for now. Following will be a few patches that modify the dirstate.status logic to use that new hierarchical information, fixing issue 6335 in the same swing. Differential Revision: https://phab.mercurial-scm.org/D9085
Fri, 24 Jul 2020 16:35:02 +0200 rust-dirstatemap: add #[timed] to dirstatemap read for comparison
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Jul 2020 16:35:02 +0200] rev 45564
rust-dirstatemap: add #[timed] to dirstatemap read for comparison Differential Revision: https://phab.mercurial-scm.org/D9084
Mon, 21 Sep 2020 11:12:58 -0700 merge: make low-level update() private (API)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 11:12:58 -0700] rev 45563
merge: make low-level update() private (API) We have very few callers left that call the low-level `merge.update()` function. I think it's time to make it private. I'll remove the remaining callers in coming patches, except for one call from the `rebase` module. I hope to eventually fix that too, but it's more complex because it requires teaching `merge.graft()` to work with a dirty working copy. Differential Revision: https://phab.mercurial-scm.org/D9065
Mon, 21 Sep 2020 10:09:39 -0700 merge: use merge.clean_update() when applicable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 10:09:39 -0700] rev 45562
merge: use merge.clean_update() when applicable We have had this higher-level function (higher than `merge.update()`, that is) for a while. Let's simply some callers by using it. I don't know why I didn't do this when I introduced the function. After this patch, there are no remaining callers that call `hg.updaterepo()` with `overwrite=True`. We'll clean that up soon. Differential Revision: https://phab.mercurial-scm.org/D9063
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 tip