D6808: revlog: introduce a `sidedata` method

[indygreg (Gregory Szorc)]

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.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6808/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6808

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