Simon Sapin <simon.sapin@octobus.net> [Tue, 06 Apr 2021 21:07:12 +0200] rev 47114
dirstate-tree: Add tree traversal/iteration
Like Python’s, Rust’s iterators are "external" in that they are driven
by a caller who calls a `next` method. This is as opposed to "internal"
iterators who drive themselves and call a callback for each item.
Writing an internal iterator traversing a tree is easy with recursion,
but internal iterators cannot rely on the call stack in that way,
they must save in an explicit object all state that they need to be
preserved across two `next` calls.
This algorithm uses a `Vec` as a stack that contains what would be
local variables on the call stack if we could use recursion.
Differential Revision: https://phab.mercurial-scm.org/D10370
Simon Sapin <simon.sapin@octobus.net> [Tue, 06 Apr 2021 14:35:39 +0200] rev 47113
dirstate-tree: Add map `get` and `contains_key` methods
Differential Revision: https://phab.mercurial-scm.org/D10369
Simon Sapin <simon.sapin@octobus.net> [Tue, 06 Apr 2021 14:29:05 +0200] rev 47112
dirstate-tree: Add parsing only dirstate parents from disk
Differential Revision: https://phab.mercurial-scm.org/D10368
Simon Sapin <simon.sapin@octobus.net> [Wed, 31 Mar 2021 18:59:49 +0200] rev 47111
dirstate-tree: Implement DirstateMap::read
This reads the on-disk dirstate in its current format (a flat sequence of
entries) and creates a tree in memory.
Differential Revision: https://phab.mercurial-scm.org/D10367
Simon Sapin <simon.sapin@octobus.net> [Thu, 08 Apr 2021 20:12:24 +0200] rev 47110
dirstate-tree: Add `WithBasename` wrapper for `HgPath`
In the tree-shaped dirstate we want to have nodes representing files or
directories, where directory nodes contain a map associating "base" names
to child nodes for child files and directories.
Many dirstate operations expect a full path from the repository root, but
re-concatenating string from nested map keys all the time might be expensive.
Instead, `WithBasename` stores a full path for these operations but
behaves as its base name (last path component) for equality and comparison.
Additionally `inclusive_ancestors` provides the successive map keys
that are needed when inserting a new dirstate node at a given full path.
Differential Revision: https://phab.mercurial-scm.org/D10365
Simon Sapin <simon.sapin@octobus.net> [Tue, 30 Mar 2021 09:56:04 +0200] rev 47109
dirstate-tree: Empty shell for a second Rust DirstateMap implementation
For background see description of the previous changeset
"Make Rust DirstateMap bindings go through a trait object".
Add an empty shell for a opt-in second Rust implementation of the
`DirstateMap` type and the `status` function. For now all methods panic.
This can be seen in "action" with:
./hg status --config experimental.dirstate-tree.in-memory=1
Differential Revision: https://phab.mercurial-scm.org/D10364
Simon Sapin <simon.sapin@octobus.net> [Thu, 08 Apr 2021 14:58:44 +0200] rev 47108
dirstate-tree: Abstract "non-normal" and "other parent" sets
Instead of exposing `HashSet`s directly, have slightly higher-level
methods for the operations that Python bindings need on them.
Differential Revision: https://phab.mercurial-scm.org/D10363
Simon Sapin <simon.sapin@octobus.net> [Tue, 30 Mar 2021 14:15:23 +0200] rev 47107
dirstate-tree: Make Rust DirstateMap bindings go through a trait object
This changeset starts a series that adds an experiment to make status faster
by changing the dirstate (first only in memory and later also on disk) to
be shaped as a tree matching the directory structure, instead of the current
flat collection of entries. The status algorithm can then traverse this tree
dirstate at the same time as it traverses the filesystem.
We (Octobus) have made prototypes that show promising results but are prone
to bitrot. We would like to start upstreaming some experimental Rust code that
goes in this direction, but to avoid disrupting users it should only be
enabled by some run-time opt-in while keeping the existing dirstate structure
and status algorithm as-is.
The `DirstateMap` type and `status` function look like the appropriate
boundary. This adds a new trait that abstracts everything Python bindings need
and makes those bindings go through a `dyn` trait object. Later we’ll have two
implementations of this trait, and the same bindings can use either.
Differential Revision: https://phab.mercurial-scm.org/D10362
Kévin Lévesque <klevesque@innovmetric.com> [Wed, 05 May 2021 18:26:04 -0400] rev 47106
remotefilelog: use the correct capability when using getfilestype threaded
The functon was overlooked when the capability was renamed
Differential Revision: https://phab.mercurial-scm.org/D10673
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47105
test-copies: test that copies' sidedata can get computed during push
If the source of the push does not have the necessary sidedata but the server
needs them, the client should compute them on the fly while pushing.
Differential Revision: https://phab.mercurial-scm.org/D10350
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47104
test-copies: test that copies' sidedata can get computed during pull
If the source does not have the data, the pulling client should compute the necessary side-data while pulling.
Differential Revision: https://phab.mercurial-scm.org/D10349
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47103
test-copies: test that copies' sidedata does not get corrupted during push
This is an important usecase.
Differential Revision: https://phab.mercurial-scm.org/D10348
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47102
test-copies: test that copies' sidedata does not get corrupted during pull
This is an important usecase.
Differential Revision: https://phab.mercurial-scm.org/D10347
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47101
test-copies: simplify some conditional output
Now that all computation using sidedata give the same result, we can
simplify conditional
Differential Revision: https://phab.mercurial-scm.org/D10346
Raphaël Gomès <rgomes@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47100
sidedata: move documentation about sidedata helpers to sidedata module
Differential Revision: https://phab.mercurial-scm.org/D10361
Raphaël Gomès <rgomes@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47099
sidedata: move sidedata-related utils to the dedicated module
Differential Revision: https://phab.mercurial-scm.org/D10360
Raphaël Gomès <rgomes@octobus.net> [Mon, 19 Apr 2021 11:22:24 +0200] rev 47098
sidedata: replace sidedata upgrade mechanism with the new one
Note: this is split into a separate change (like some other patches in this
series) because it's not easy to have all patches work 100% and this seemed
easier for reviewers.
When cloning or upgrading a repo, we may need to compute (or remove) sidedata.
This is the same mechanism that is used in exchange, so we re-use the new
system to simplify the code and fix the remaining issues (correctly dropping
flags and handling partial removal, etc.).
This also highlighted an issue with `test-copies-in-changeset.t` that kept
sidedata categories that are not relevant anymore. They should probably be
dropped entirely, but that would be for another patch.
Differential Revision: https://phab.mercurial-scm.org/D10359
Raphaël Gomès <rgomes@octobus.net> [Mon, 19 Apr 2021 11:22:21 +0200] rev 47097
sidedata: add a way of replacing an existing sidedata computer
This will be useful in a future patch to replace a sequential computer with
a parallel computer. We only allow for explicit replacement, to force the users
to think about overriding computers.
Differential Revision: https://phab.mercurial-scm.org/D10358
Raphaël Gomès <rgomes@octobus.net> [Thu, 08 Apr 2021 16:30:10 +0200] rev 47096
bundle2: remove restriction around sidedata
We are now capable of generating the missing sidedata on-the-fly.
Differential Revision: https://phab.mercurial-scm.org/D10345
Raphaël Gomès <rgomes@octobus.net> [Thu, 08 Apr 2021 16:55:17 +0200] rev 47095
sidedata: enable sidedata computers to optionally rewrite flags
Sidedata computers may want to influence the flags of the revision they touch.
For example, the computer for changelog-based copytracing can add a flag to
signify that this revision might affect copytracing, inversely removing said
flag if the information is no longer applicable.
See inline documentation in `storageutil` for more details.
Differential Revision: https://phab.mercurial-scm.org/D10344
Raphaël Gomès <rgomes@octobus.net> [Sat, 10 Apr 2021 11:27:40 +0200] rev 47094
cg4: introduce protocol flag to signify the presence of sidedata
We need a way of signaling whether the current revision has sidedata or not,
and re-using the revision flags would waste potential revlog flags and mix two
normally independent layers.
In this change, we add a single byte at the start of the ch4 delta header to
set potential protocol flags. We also reclaim the revlog flag for sidedata,
since it is no longer used, in its place now lives the (also experimental)
copytracing flag.
When generating deltas, apply the `CG_FLAG_SIDEDATA` flag if there is sidedata.
When applying the deltas, if said flag is present, the next chunk contains the
sidedata.
Differential Revision: https://phab.mercurial-scm.org/D10343
Raphaël Gomès <rgomes@octobus.net> [Thu, 08 Apr 2021 16:34:11 +0200] rev 47093
changegroup: don't limit cgv4 to revlogv2 repos
To help the transition from revlogv1 to revlogv2, we need to be able to enable
cgv4 for revlogv1 repos, so that revlogv2 clients can handle adding/removing
sidedata over the wire.
Differential Revision: https://phab.mercurial-scm.org/D10342
Raphaël Gomès <rgomes@octobus.net> [Thu, 08 Apr 2021 16:39:39 +0200] rev 47092
sidedata: gate sidedata functionality to revlogv2 in more places
Since revlogv1 is not capable of storing sidedata, we prevent sidedata
mechanisms around the revlog layer from doing anything. We however keep the
ones that allow a revlogv1 repo to generate sidedata on-the-fly on a push, the
pull case simply does not add the sidedata to the revlog.
Differential Revision: https://phab.mercurial-scm.org/D10341
Raphaël Gomès <rgomes@octobus.net> [Tue, 30 Mar 2021 17:03:02 +0200] rev 47091
sidedata: register copies sidedata computer regardless of the revlog version
Repositories should not gate their sidedata computers based on any requirement,
only their wanted sidedata. A repository might need to generate sidedata wanted
by the peer that it itself does not want.
Differential Revision: https://phab.mercurial-scm.org/D10340
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Apr 2021 19:00:21 +0200] rev 47090
revlog: replace the old `revlog_kind` approach with the new `target` one
The new `target` attribute supersedes the previous one.
Differential Revision: https://phab.mercurial-scm.org/D10353
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 06 Apr 2021 05:20:24 +0200] rev 47089
revlog: introduce an explicit tracking of what the revlog is about
Since the dawn of time, people have been forced to rely to lossy introspection
of the index filename to determine what the purpose and role of the revlog they
encounter is. This is hacky, error prone, inflexible, abstraction-leaky,
<insert-your-own-complaints-here>.
In f63299ee7e4d Raphaël introduced a new attribute to track this information:
`revlog_kind`. However it is initialized in an odd place and various instances
end up not having it set. In addition is only tracking some of the information
we end up having to introspect in various pieces of code.
So we add a new attribute that holds more data and is more strictly enforced.
This work is done in collaboration with Raphaël.
The `revlog_kind` one will be removed/adapted in the next changeset. We expect
to be able to clean up various existing piece of code and to simplify coming
work around the newer revlog format.
Differential Revision: https://phab.mercurial-scm.org/D10352
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 May 2021 08:54:28 -0700] rev 47088
config: add --source option to include source of value
Showing the source of each config option is quite useful and not
something the user should have to reach for the `--debug` flag for.
I updates documentation and tests, except for one place in
`test-hgrc.t` where I thought the test might have been intended to
also test that `--debug` results in `ui.quiet` etc being test.
Differential Revision: https://phab.mercurial-scm.org/D10668
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 May 2021 10:49:32 -0700] rev 47087
rewriteutil: say how many commits would become orphan if commit is rewritten
This copies the message from the evolve extension, but modifies it a
bit to work with the grammar (in particular with the use of "change
branch of" as `action`). I don't know why it doesn't use the same
`_formatrevs()` as for public commmits.
Differential Revision: https://phab.mercurial-scm.org/D10671
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 May 2021 10:16:34 -0700] rev 47086
rewriteutil: give examples of public changesets that can't be rewritten
This patch copies the feature from the evolve extension.
Differential Revision: https://phab.mercurial-scm.org/D10670
Augie Fackler <augie@google.com> [Mon, 03 May 2021 15:14:09 -0400] rev 47085
merge: with stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 03 May 2021 18:55:19 +0200] rev 47084
branching: merge stable into default
Joerg Sonnenberger <joerg@bec.de> [Fri, 30 Apr 2021 02:11:58 +0200] rev 47083
manifests: push down expected node length into the parser
This strictly enforces the node length in the manifest lines according
to what the repository expects. One test case moves large hash testing
into the non-treemanifest part as treemanifests don't provide an
interface for overriding just the node length for now.
Differential Revision: https://phab.mercurial-scm.org/D10533