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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel