This feels substantially more appropriate, as the store is actually
the layer with knowledge of how to handle this storage. I didn't move
the caching decorators for now because that's going to require some
more involved work, and this unblocks my current experimentation.
Details
Details
- Reviewers
indygreg pulkit - Group Reviewers
hg-reviewers - Commits
- rHG3df3b139a43d: localrepo: push manifestlog and changelog construction code into store
Diff Detail
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Comment Actions
The boundary between localrepository and store is a bit murky and definitely needs some work. When I last had things paged into my brain last year, I think I was trending towards breaking up the store into discrete classes and making the code that dynamically resolves repository types cherry pick the classes depending on the opener options. But we could easily have the store handle this logic as well. This is all very complicated and I don't prescribe to have a single correct answer.
Comment Actions
I think pushing it down into the store makes a reasonable amount of sense, since it's going to be pretty heavily tied to the revision storage mechanism...