manifest: rename manifestlog._treeinmem to ._treemanifests Not sure what "inmem" was supposed to indicate. This object is an interface to manifest data on disk as well as "in memory" (assuming that's what "inmem" means). Differential Revision: https://phab.mercurial-scm.org/D4278

manifest: add getstorage() to manifestlog and use it globally It is a common pattern to obtain a directory manifest storage instance (a manifestrevlog) by going through manifestlog._revlog.dirlog(). Why access to storage and caching of other manifests is done through manifestrevlog instead of manifestlog, I don't know. This commit establishes a getstorage(tree) API on manifestlog and imanifestlog that provides a public API for accessing manifest storage. All consumers previously using private attributes have been updated to use this new method. .. api:: manifestlog now has a getstorage(tree) method It should be used for obtaining an object representing the manifest's storage implementation. Accessing manifestlog._revlog should be avoided. Differential Revision: https://phab.mercurial-scm.org/D4277

manifest: rename dir argument and attribute to tree dir shadows a built-in. We use it throughout the manifest code, which is unfortunate. This commit updates just manifestrevlog to be more well behaved. .. api:: renamed manifest.manifestrevlog.__init__ dir argument to tree Differential Revision: https://phab.mercurial-scm.org/D4276

manifest: set appropriate cache entry when clearing _dirlogcache() manifestrevlog applies to any manifest, not just the root manifest. Resetting the cache and populating its root entry with self is not correct when the instance does not refer to the root manifest. This has no test fallout. So I'm guessing we only ever call clearcaches() on the root manifest. Or we have no test coverage that are impacted by a bad cache on a non-root manifestrevlog. Differential Revision: https://phab.mercurial-scm.org/D4275

manifest: remove addgroup() from manifestlog and imanifestlog addgroup() is part of the storage interface for manifests. Unfortunately, we don't yet have a formal storage interface for manifests. (One will be established in subsequent commits.) One thing is for sure, addgroup() doesn't belong on imanifestlog - at least not unless we extend that interface to encompass storage. For now, let's access addgroup() on the _revlog attribute, just like we do for tree manifests. Even though this violates visibility, it is consistent. Differential Revision: https://phab.mercurial-scm.org/D4274

repository: clarify role of imanifestlog Looking at the implementation of manifest.manifestlog, it is highly tailored towards servicing the root manifest. So clarify that in the interface docstring. Differential Revision: https://phab.mercurial-scm.org/D4273