remotefilelog: rip out lz4 support
ClosedPublic

Authored by durin42 on Oct 11 2018, 8:22 AM.

Details

Summary

Some methods are left teased out so it's easier to build a migration
extension from v1 packs to v2. I also anticipate those methods will be
of use if we get around to adding configurable compression engines
before we end up jettisoning packs.

I think it would make sense to register one-shot compress and
decompress methods on our compression engines in util.py, but
indygreg mentioned that might not be straightforward.

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.
durin42 created this revision.Oct 11 2018, 8:22 AM
indygreg accepted this revision as: indygreg.Oct 16 2018, 3:46 AM
indygreg added a subscriber: indygreg.

Get that non-standard LZ4 format outta here!

Yes, we should probably add a compression engine API for doing one-shot compression/decompression. I could use that in the SQLite extension. If you don't implement it, I may do it for you in the natural course of making that extension :)

I'm holding off formally accepting as a reviewer because the patch is marked WIP.

Please resubmit without that.

I'll need to take a pass over the final version of this code before committing. But I'm pretty sure the current state of this series is good enough or pretty close to being landable.

hgext/remotefilelog/datapack.py
306–310

Yes we should. But this is no worse than revlogs.

durin42 updated this revision to Diff 12182.Oct 16 2018, 3:18 PM
durin42 edited the summary of this revision. (Show Details)
durin42 retitled this revision from remotefilelog: rip out lz4 support (WIP) to remotefilelog: rip out lz4 support.
indygreg accepted this revision.Oct 17 2018, 2:51 AM
This revision is now accepted and ready to land.Oct 17 2018, 2:51 AM
This revision was automatically updated to reflect the committed changes.