Manifest Refactor

[Martin von Zweigbergk]

If you do, please invite me too. But I suppose we shouldn't be doing that
until after the freeze :-)

On Tue, Jul 19, 2016 at 5:22 AM Augie Fackler <raf at durin42.com> wrote:

> At a high level, this looks fine to me. If you want, we can find some
> time in the next couple of weeks for me to go over your series in
> advance.
>
> AF
>
> On Mon, Jul 18, 2016 at 4:06 PM, Durham Goode <durham at fb.com> wrote:
> > The final design has come out looking like the following.  It mirrors the
> > changelog pretty closely, with ctx objects of various implementations,
> and
> > memctx objects for representing pending inmemory manifests.  There is no
> > manifest.manifest class after this.
> >
> > class manifestlog(object):
> >     def __init__(self, opener, revlog)
> >     def __getitem__(self, node): return self.get(node)
> >     def get(self, node, dir='')
> >     def add(self, m, transaction, link, p1, p2...): return
> > m.write(transaction, ...)
> >
> > class manifestrevlog(revlog):
> >     def dirlog(self, dir)
> >
> > class manifestctx(manifestdict):
> >     def new(self)
> >     def node(self)
> >     def p1(self)
> >     def p2(self)
> >     def linkrev(self)
> >     def readfast(self, shallow=False)
> >     def readdelta(self, shallow=False)
> >
> > class treemanifestctx(treemanifest)
> >     <same as manifestctx>
> >
> > class memmanifestctx(manifestdict):
> >     def new(self)
> >     def write(self, transaction, link, p1, p2, ....)
> >
> > class memtreemanifestctx(treemanifest):
> >     <same as memmanifestctx>
> >     def _addtree(...)
> >
> >
> > Notes:
> >
> > - All the nasty if-tree-else-flat conditions are gone thanks to them
> being
> > separate classes
> >
> > - All revlog specific operations can be accessed via
> > repo.manifestlog._revlog, but it has no manifest specific logic on the
> > revlog anymore.
> >
> > - The actual manifest.py can be found
> https://bpaste.net/show/ef4b138f9083 .
> > I have a 30 patch series that makes the transformation, so I'll start
> > sending that out in small chunks soon.
> >
> >
> >
> >
> > On 7/12/16 3:03 PM, Durham Goode 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160719/02cde5d0/attachment.html>