[PATCH] treemanifest: store submanifest revlog per directory

Martin von Zweigbergk martinvonz at google.com
Fri May 15 07:20:08 CDT 2015


I think it will be optional forever, because it will probably generally be
faster with flat manifests for small and medium-sized projects. Also note
that the format is hidden behind an experimental config option, so we can
still modify the format after this commit until we move the format out of
experimental.

I'm still curious to hear what you had in mind regarding changes to the
format.

On Thu, May 14, 2015, 22:52 Adrian Buehlmann <adrian at cadifra.com> wrote:

> On 2015-05-15 00:49, Martin von Zweigbergk wrote:
> > # HG changeset patch
> > # User Martin von Zweigbergk <martinvonz at google.com>
> > # Date 1428992462 25200
> > #      Mon Apr 13 23:21:02 2015 -0700
> > # Node ID 01586fff55933fd0eb58e61a123d4c7b03258bd3
> > # Parent  d1bd0fd07ee6adf4ab3be2b0a0a7c0df54d55abf
> > treemanifest: store submanifest revlog per directory
> >
> > With this change, when tree manifests are enabled (in .hg/requires),
> > commits will be written with one manifest revlog per directory. The
> > manifest revlogs are stored in
> > .hg/store/meta/$dir/00manifest.[id].
>
> If this new treemanifest format gets popular in the future, am I right
> in assuming that this is intended as the default format in the future?
>
> Or is it intended to remain an optional format forever?
>
> I'm asking this because I think it might be worth investing a bit more
> thinking into the layout on disk, especially if the plan is to use
> treemanifest per default in the future.
>
> As soon as this new format is engraved in stone, mercurial will
> obviously have to live with it until its death.
>
> Note: I'm the author of the current fncache format. And I know what it
> means if one has to live with decisions made. For example, when I
> created the freaky encoding in store._hashencode, I didn't imagine back
> then that someone would ever want to translate that complicated piece
> into C. I'm not saying that I would want to (ab)use your layout change
> to revisit that decision. I'm just saying that I've 'been there'.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150515/7f1cb956/attachment.html>


More information about the Mercurial-devel mailing list