Manifest Refactor

Durham Goode durham at fb.com
Mon Jul 18 16:06:58 EDT 2016


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).


More information about the Mercurial-devel mailing list