It's good for both making Revlog testable and reusable to have it
not depend on the higher-level Repo type. This patch is one step in
towards that. Additionally, this change in particular gives the
callers more control over when to use a nodemap.
Details
Details
- Reviewers
Alphare - Group Reviewers
hg-reviewers
Diff Detail
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
Comment Actions
While I think you're right about separating the revlogs from the repo, the repeated logic should probably be factored into a function somewhere. Why not in nodemap.rs?
Comment Actions
Two things:
- Do we want to use persistent nodemaps for all types of revlogs? This was what I meant by "Additionally, this change in particular gives the callers more control over when to use a nodemap.". Looking at the Python code, we don't seem to use it for filelogs. I'll add a patch to this series to stop using persistent nodemap for filelogs.
- I was thinking of moving the conditions further up the stack, to the repo level. If we do that, then the repo might be a natural place to extract a function. Or maybe I'll put it in nodemap.rs as you said. I'll update this patch a bit later.
Comment Actions
We will probably only want it for changelogs and manifestlogs. Thanks for sending the patch for the filelogs. Maybe that'll change in the future (with unified revlog?), but that can always be added.
- I was thinking of moving the conditions further up the stack, to the repo level. If we do that, then the repo might be a natural place to extract a function. Or maybe I'll put it in nodemap.rs as you said. I'll update this patch a bit later.
Either seem fine to me.