D6808: revlog: introduce a `sidedata` method

indygreg (Gregory Szorc) phabricator at mercurial-scm.org
Sat Sep 7 13:20:04 EDT 2019

indygreg added a comment.

  I think I see where you are going with this and it seems potentially very useful.
  I do wish the flag processors code could have been refactored without involving `sidedata`, as I would have taken the patches later in this series to remove the temporary `mixin` in a heartbeat. But since `sidedata` is involved, I want to have others weigh in.
  It would be extremely useful to see an actual use case for `sidedata`. As it stands, I have questions like whether we'll need to further evolve the storage APIs to accommodate things like cherry-picking which pieces of `sidedata` are desired. Also, incorporating `sidedata` in the revlog write APIs (in later patches) seems a bit odd, as the revlog format is rather stable and I'm not sure how additional data will be incorporated without introducing a new flag processor to accommodate extra data next to the revision. Again, I'd really like to see a real world use case for `sidedata` to help give me confidence this is the correct storage abstraction.

  rHG Mercurial



To: marmoute, yuja, durin42, indygreg, #hg-reviewers
Cc: mercurial-devel

More information about the Mercurial-devel mailing list