The rust code was building tuple.
Details
- Reviewers
SimonSapin Alphare - Group Reviewers
hg-reviewers - Commits
- rHG7a15dea6d303: dirstate-item: also build DistateItem in dirstate.directories()
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
I think future changes of DirstateItem internals will be easier if state == 'd' is never something we need to represent in DirstateItem. We can do that by changing directories to return a list of (path, mtime) instead of (path, DirstateItem), and updating the two callers (debugcommands.debugdirstate and dirstate.foldmap).
I am not too convinced that treating directory in a different way is win. What's your motivation there ?
Currently a dirstatetuple / dirstateitem only exists for paths that are present in dirstate-v1 and for which dirstate.__contains__ returns true. It contains a state whose value is always n, a, r, or m. However we want to move towards not having this state at all other than in dirstate-v1 parsing and serialization. Adding more cases to handle makes that more difficult and isn’t necessary.
In Rust code the DirstateEntry struct corresponds to dirstatetuple / dirstateitem. Current in the tree dirstate map, "directory" nodes don’t have a DirstateEntry at all. (And soon entry-less nodes won’t be just directories but will also potentially include ignored or unknown files.) When adding this directories iterator I only made it create tuples that look kinda like dirstatetuple as a shortcut because that’s what debugcommands.debugstate was already handling.
Given that we are moving toward adding more thing in the dirstate(map) in general, having an explicit entry for all of them, instead of various special case, seems simpler. I expect us to introduce dedicated boolean property to differenciate the one Mercurial will directly care about (tracked in wc on in parent) and the other ones.
Alright, we’re not gonna decide right now the future internals of dirstateitem so let’s take this patch and we can always change things again later. We’ll probably need to separate the two users of this iterator anyway:
- Now that tree-based hasdir is based on "the counter of descendants with an entry is zero" instead of just "this node does not have an entry", foldmap should be changed in a same way
- debugdirstate wants all nodes with the maximum of information. That could be a single iterator instead of having it combine values from two iterators.
rust/hg-cpython/src/dirstate.rs | ||
---|---|---|
79 | https://dgrunwald.github.io/rust-cpython/doc/cpython/macro.py_capsule.html says "with a layer of caching" so it should be fine. |
rust/hg-cpython/src/dirstate.rs | ||
---|---|---|
79 | Yeah, it's using a OnceCell, so this is at most a very tiny difference to performance. |
https://dgrunwald.github.io/rust-cpython/doc/cpython/macro.py_capsule.html says "with a layer of caching" so it should be fine.