I'm talking about keeping at least one of the current, widely supported formats around, which I think would limit hardship for existing users. I'm sort of curious how many full-history-dump users there are and if they have anything to say. You mentioned porting; histzip is a Go program that's easy to cross-compile for different OSes/architectures (as I have for Windows/Mac/Linux on the github page, though not various BSDs).
I would definitely recommend talking to Igor Pavlov (7-Zip) about this,
he might be interested in having this as part of 7-Zip as some kind of
"fast" option, and also the developers of the `xz` tools. There might
even be ways this could fit within existing extensibility mechanisms of
the formats.
7-Zip is definitely a very cool and flexible program. I think it can actually run faster than it's going in the current dumps setup: -mx=3 maintains ratios better than bzip's, but runs faster than bzip. That's a few times slower than histzip|bzip and slightly larger output, but it's a boost from the status quo. (There's an argument for maintaining that, not bzip, as the widely-supported format, which I'd mentioned in the xmldatadumps-l branch of this thread, or for just changing the 7z settings and calling it a day)
Interesting to hear from Nemo that Pavlov was interested in long-range zipping. histzip doesn't have source he could drop into his C program (it's in Go) and it's really aimed at a narrow niche (long repetitions at a certain distance) so I doubt I could get it integrated there.
Anyway, I'm saying too many fundamentally unimportant words. If the status quo re: compression in fact causes enough pain to give histzip a fuller look, or if there's some way to redirect the tech in it towards a useful end, it would be great to hear from interested folks; if not, it was fun work but there may not be much more to do or say.