Manifest Refactor

Durham Goode durham at fb.com
Tue Jul 19 12:49:29 EDT 2016


I can make the stack available on bitbucket for people to peruse and give basic comments on at least: https://bitbucket.org/DurhamG/hg/commits/branch/manifestrefactor  It’s not quite a final stack (treemanifestctx needs to be lazily initialized and some of the commits need some cleanup, comments, and better commit messages).

From: Martin von Zweigbergk <martinvonz at google.com>
Date: Tuesday, July 19, 2016 at 9:30 AM
To: Augie Fackler <raf at durin42.com>, Durham Goode <durham at fb.com>
Cc: mercurial-devel <mercurial-devel at mercurial-scm.org>, Tony Tung <tonytung at instagram.com>, Gregory Szorc <gregory.szorc at gmail.com>
Subject: Re: Manifest Refactor

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<mailto: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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=https-3A__bpaste.net_show_ef4b138f9083&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=nuarHzhP1wi1T9iURRCj1A&m=JsX2nG9CzG0mJUBXNryByh-bM5C_h5ZzRaxh2YXROQs&s=oSilNIQuf1Nf7R54BzmHmqWLMlHl2HLOh1Bd5I2GaxE&e=> .
> 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/509b376a/attachment.html>


More information about the Mercurial-devel mailing list