In this implementation, we are in direct competition
with the C version: this Rust version will have a clear
startup advantage because it will read the data from disk,
but the insertion happens all in memory for both.
Details
- Reviewers
 kevincox marmoute - Group Reviewers
 hg-reviewers - Commits
 - rHGd2da8667125b: rust-nodemap: insert method
 
Diff Detail
- Repository
 - rHG Mercurial
 - Branch
 - default
 - Lint
 No Linters Available - Unit
 No Unit Test Coverage 
Event Timeline
| rust/hg-core/src/revlog/nodemap.rs | ||
|---|---|---|
| 270 | It looks like this return value could use some abstraction but maybe its best to wait until there are more users?  | |
| 275 | I don't quite understand. You have the immutable copy and the mutable copy but that is WAI right?  | |
| 308 | nybble is very vague. Is this deepest_nibble or something?  | |
| 506 | Should these be #[cfg(test)]? We can always remove it later if there is a valid production use but it makes new users think twice.  | |
The change seesm good to me. However kevincox proposal to use #[cfg(test)] for pad_node seems worth applying inflight.
| rust/hg-core/src/revlog/nodemap.rs | ||
|---|---|---|
| 270 | In pratice this function should have very few user, and they will all be internal. So I am not sure we need something more advanced.  | |
| 308 | This seems to have been updated because the code no longer mention nible on that line.  | |
| 506 | This seems like a good idea.  | |
For future reference, I'm going to add it here, but if you're going to the trouble of uploading a new revision, it would have been nice to do this and save reviewer toil.
I juste rebased the revision on a more modern tip. I did not actually touched anything inside it.
It looks like this return value could use some abstraction but maybe its best to wait until there are more users?