[PATCH 3 of 3 V3] chgcache: implement repocache

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-03-11 12:54:17 -0800:
> On Tue, 7 Mar 2017 22:35:59 -0800, Jun Wu wrote:
> > # HG changeset patch
> > # User Jun Wu <quark at fb.com>
> > # Date 1488953311 28800
> > #      Tue Mar 07 22:08:31 2017 -0800
> > # Node ID d136f214b3a5bd4698dfd96c641ad73f96a743cb
> > # Parent  f0bded8d53c5c9a5cfb25d29dd99cf4eb3fb79b2
> > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > #              hg pull https://bitbucket.org/quark-zju/hg-draft  -r d136f214b3a5
> > chgcache: implement repocache
> 
> > +repoloadfunctable = {'changelog': loadchangelog}
> > +
> > +ui = uimod.ui()
> > +ui.setconfig('ui', 'allowemptycommit', '1')
> > +
> > +repo = localrepo.localrepository(
> > +    ui,
> > +    os.path.join(os.environ['TESTTMP'], 'repo1'),
> > +    create=True)
> > +repocache = chgcache.repocache(repo, repoloadfunctable)
> 
> Suppose a cache object is attached to a repo by chgserver, do we really
> need a global _cache storage?

One design goal is to decouple low-level API from repo. i.e. chgcache could
be used to cache non-repo objects.

Extensions are an example of non-repo objects that could benefit from the
design. Workers could send new extensions to the master, and the master
could have better "extension cache hit rate" after reloading extensions.
Unlike the current "start new server for new extensions" behavior. The new
design allows us to serve the request using the old server sub-optimally,
and start a more efficient server in the background to replace the current
one soon.

A fb-only example is that remotefilelog uses repo-independent packfiles.

I think the cache state is conceptually attached to the current process,
instead of repo. Thus a global may actually be a better fit. We want the
behavior that "fork()" copies the state, and don't care if fork() should
copy the repo object or not.