This wires into dirstatemap the parser and serializer added in previous
changesets. The memory representation is still the same, with a flat dict
for DirstateItems and another one for copy sources. Serialization always
creates a new dirstate-v2 data file and does not support (when Rust is not
enabled) appending to an existing one, since we don’t keep track of which
tree nodes are new or modified. Instead the tree is reconstructed during
serialization.
Details
- Reviewers
marmoute pulkit - Group Reviewers
hg-reviewers - Commits
- rHGb4f83c9e7905: dirstate-v2: Add support when Rust is not enabled
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
The current project policy is not to blindly add slow support for this new format. We should make it possible to supports it, but disabled by default.
For comparison, see what is done for the persistent-nodemap format variable through the storage.revlog.persistent-nodemap.slow-path config option.
mercurial/dirstatemap.py | ||
---|---|---|
38–39 | The creation if this class should probably goes into a different changeset than the addition of the python support for v2, it would make it clearer which part are about factoring code out and which part is about adding support for v2 in Python. | |
40 | idertical → identical |
I’ve rebased this on top of D11655 and changed the Python parser and serializer to match recent changes to the Rust ones. Unfortunately this has to be done by carefully looking at both implementation and the docs, since we don’t yet have tests that show compatibility between the Rust serializer and Python parser, or vice-versa.
Also there’s a new test failure in test-dirstate-race.t#dirstate-v2 that I don’t understand. It’s only in pure-Python mode, and has three chunks like this:
$ hg debugdirstate n 644 2 * a (glob) - n 0 -1 unset b - n 0 -1 unset d - n 0 -1 unset dir1/c - n 0 -1 unset e + n 644 -1 unset b + n 644 -1 unset d + n 644 -1 unset dir1/c + n 644 -1 unset e
The creation if this class should probably goes into a different changeset than the addition of the python support for v2, it would make it clearer which part are about factoring code out and which part is about adding support for v2 in Python.