Wed, 19 May 2021 13:15:00 +0200 rust: Return owned instead of borrowed DirstateEntry in DirstateMap APIs
Simon Sapin <simon.sapin@octobus.net> [Wed, 19 May 2021 13:15:00 +0200] rev 47332
rust: Return owned instead of borrowed DirstateEntry in DirstateMap APIs This will enable the tree-based DirstateMap to not always have an actual DirstateEntry in memory for all nodes, but construct it on demand. Differential Revision: https://phab.mercurial-scm.org/D10746
Wed, 19 May 2021 13:15:00 +0200 dirstate-tree: Downgrade `&mut Node` to `&Node` in status and serialization
Simon Sapin <simon.sapin@octobus.net> [Wed, 19 May 2021 13:15:00 +0200] rev 47331
dirstate-tree: Downgrade `&mut Node` to `&Node` in status and serialization Mutable access is not used, and upcoming changes will make it more costly (with copy-on-write nodes that can be read from disk representation) Differential Revision: https://phab.mercurial-scm.org/D10745
Wed, 19 May 2021 13:15:00 +0200 dirstate-tree: Remove DirstateMap::iter_node_data_mut
Simon Sapin <simon.sapin@octobus.net> [Wed, 19 May 2021 13:15:00 +0200] rev 47330
dirstate-tree: Remove DirstateMap::iter_node_data_mut In an upcoming changeset we want DirstateMap to be able to work directly with nodes in their "on disk" representation, without always allocating corresponding in-memory data structures. Nodes would have two possible representations: one immutable "on disk" refering to the bytes buffer of the contents of the .hg/dirstate file, and one mutable with HashMap like the curren data structure. These nodes would have copy-on-write semantics: when an immutable node would need to be mutated, instead we allocate new mutable node for it and its ancestors. A mutable iterator of the entire tree would still be possible, but it would become much more expensive since we’d need to allocate mutable nodes for everything. Instead, remove this iterator. It was only used to clear ambiguous mtimes while serializing the `DirstateMap`. Instead clearing and serialization are now two separate passes. Clearing first uses an immutable iterator to collect the paths of nodes that need to be cleared, then accesses only those nodes mutably. Differential Revision: https://phab.mercurial-scm.org/D10744
Fri, 28 May 2021 17:33:20 -0400 merge with stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 28 May 2021 17:33:20 -0400] rev 47329
merge with stable
Wed, 26 May 2021 21:46:45 +0200 revlog: close the index file handle after the data one
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 26 May 2021 21:46:45 +0200] rev 47328
revlog: close the index file handle after the data one This make sure the data file is flushed before the index. preventing the index to reference unflushed data. Differential Revision: https://phab.mercurial-scm.org/D10776
Wed, 26 May 2021 21:35:51 +0200 revlog: simplify the try nesting in the `_writing` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 26 May 2021 21:35:51 +0200] rev 47327
revlog: simplify the try nesting in the `_writing` context Lets use a single try, with conditional cleanup. This make is easier to add a file handle dedicated to sidedata. Differential Revision: https://phab.mercurial-scm.org/D10775
Thu, 20 May 2021 21:54:21 +0200 revlogv2: add a `get_data` helper to grab the next piece of docket
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 20 May 2021 21:54:21 +0200] rev 47326
revlogv2: add a `get_data` helper to grab the next piece of docket This make the processing more compact but abstracting repetitive processing away. Differential Revision: https://phab.mercurial-scm.org/D10774
Thu, 20 May 2021 21:48:53 +0200 revlogv2: simplify and clarify the processing of each entry
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 20 May 2021 21:48:53 +0200] rev 47325
revlogv2: simplify and clarify the processing of each entry As we add more entries and some of them has non trivial processing it seems useful to make the processing leaner and clearly separated to simplify futures patches. Differential Revision: https://phab.mercurial-scm.org/D10773
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 tip