[PATCH 3 of 3 V3] chgcache: implement repocache

[Yuya Nishihara]

On Sat, 11 Mar 2017 17:21:41 -0800, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-03-11 15:50:43 -0800:
> > On Sat, 11 Mar 2017 14:54:54 -0800, Jun Wu wrote:
> > > 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.
> > 
> > Yeah, it will live longer than a repo, and will reside in dispatcher level,
> > which I don't think mean the data should be globally accessible by anyone.
> 
> It sounds like it could be done by split the "global" in chgcache states
> into different modules: chgserver, dispatch, ...
> 
> In that case, adding a new parameter to "smartcache" to decouple it from
> chgcache._cache seems to address the issue.
> 
> It sounds possible, but I need more time to make sure it works.

Maybe something like that. Since most data to be cached would be repo-dependent,
we don't need a global namespace for cache content. We can just attach repocache
per repo and its content can be managed by the server.

  cache = {repo.root: repostrage}    # managed by chg server
  repo.repocache = cache[repo.root]  # maybe by chg ui/req hook?
  changelog.repocache = repo.repocache  # passed by repo

For remotefilelog which prefers wider cache, maybe it can manage its own cache
storage? I haven't consider well how it should be invalidated, though.