durham at fb.com
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 fb.com> 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 fb.com> wrote:
>>>> We'll be looking at moving to tree manifests as our source of truth over
>>>> next few months, and one problem area is the fact that the manifest class
>>>> not well factored for this usecase. This one class is the collection of
>>>> manifests, the accessor for information about individual manifests, and
>>>> storage format (revlog).
>>>> Before I do a bunch of work, I wanted to run my proposal for breaking up
>>>> 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)
>>>> basically what repo.manifest would return, and mainly consist of "get"
>>>> "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
> manifestlog.read(node) that returns a manifest on which you can then
> call delta() on to get a delta. So e.g. manifestlog.read(node).keys()
> gives you all the files in the manifest, while
> manifestlog.read(node).delta().keys() 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