Manifest Refactor

Durham Goode durham at
Thu Jul 14 19:56:44 EDT 2016

On 7/14/16 4:54 PM, Martin von Zweigbergk wrote:
> On Thu, Jul 14, 2016 at 4:35 PM, Durham Goode <durham at> wrote:
>> On 7/14/16 3:38 PM, Martin von Zweigbergk wrote:
>>> On Tue, Jul 12, 2016 at 3:03 PM, Durham Goode <durham at> wrote:
>>>> We'll be looking at moving to tree manifests as our source of truth over
>>>> the
>>>> next few months, and one problem area is the fact that the manifest class
>>>> is
>>>> not well factored for this usecase. This one class is the collection of
>>>> all
>>>> manifests, the accessor for information about individual manifests, and
>>>> the
>>>> storage format (revlog).
>>>> Before I do a bunch of work, I wanted to run my proposal for breaking up
>>>> the
>>>> manifest by you guys:
>>>> 1. Add a "manifestlog" class that represents the collection of all
>>>> root-level manifests (i.e. what commits point to; not any sub-trees)
>>>> It's
>>>> basically what repo.manifest would return, and mainly consist of "get"
>>>> and
>>>> "add" apis that return and accept manifest instances.
>>> As Augie said elsewhere in this thread, there's more than "get"
>>> (actually called "read") and "add" in the current API. Where would you
>>> put the dirlog() function that's currently on manifest? It may be
>>> useful to include a list of the classes you imagine and their methods
>>> (but skip the uninteresting ones), so we can see clearly where each
>>> method goes.
>> I'm aware of readdelta and dirlog.  readdelta would be moved onto the
>> manifest instance (since you are asking the specific instance a piece of
>> information about itself).  This would mean we don't have to have if
>> conditions all over the manifestlog class special casing tree vs not-tree.
> The manifest instances are currently created by read() and readdelta()
> etc. I think you're proposing that there would be a single
> that returns a manifest on which you can then
> call delta() on to get a delta. So e.g.
> gives you all the files in the manifest, while
> gives you the files in the
> delta. Am I understanding that right? I think that means you're also
> proposing that the manifest class will lazily read the full or delta
> (otherwise there's not much point in asking for the delta if you have
> to read the full version too). Correct?

More information about the Mercurial-devel mailing list