On Tue, Jan 05, 2021 at 04:38:20PM +0100, Raphaël Gomès wrote: > I've opened a very much draft plan page [1] to try to list all the things we > want to do in that version and try to figure out an efficient new format.
"No support for hash version" I don't think that points really matters. The plan for the hash migration allows them in theory to coexist fully on the revlog layer and the main problems for mixing them are on the changeset/manifest layer anyway. That is, any migration strategy will IMO rewrite all revlogs to the newer hash anyway and only keep a secondary index for changesets and maybe manifests. "No support for sidedata" My big design level concern is that revlog ATM is optimized for fast integer indexing and append-only storage. At least for some sidedata use cases I have, that is an ill fit. "No support for unified revlog" IMO this should be the driving feature. The biggest issue for me is that it creates two challenges that didn't exist so far: (1) Inter-file patches and how they interact with the wire protocol (2) Identical revisions stored in different places. "No support for larger files" Supporting large revlog files is sensible and having a store for design-challenged file systems might be necessary. Microsoft, I'm looking at you. Otherwise the concern is space use in the revlog file and RAM use during operations. I don't think the latter is as big an issue now as it was 15 years ago, but the former is real. But it might be a good point in time to just go for 64bit offsets by default... Joerg _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
