[PATCH 2 of 4 V2] chgcache: report repo paths from worker to master

[Yuya Nishihara]

On Wed, 1 Mar 2017 12:38:44 -0800, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-02-28 23:04:52 +0900:
> > Perhaps this is related to the baselocalrepostiroy-vs-repostorage story.
> > Maybe we'll have to settle it first?
> > 
> > My view is that there will be a repostorage object, which will be looked
> > up at dispatch layer and be injected into a localrepository object. So
> > localrepo can ideally go without knowing chgcache.
> > 
> >   dispatch (or hook carried by req object) cached_storage =
> >   chgcache.lookup(root) attach_storage_in_some_way(repo, cached_storage)
> > 
> > In this view, it makes sense to record the repo path here.
> 
> I think the repostorage refactoring is relatively separate from chgcache,
> and it could be a big project (partially because of compatibility with
> existing extensions), so I'd prefer avoiding it for now.
> 
> My understanding about chgcache is:
> 
>   - It's low-level, like a key-value storage (ex. memcache)
>   - Its repo stuff is just to make it easier to write preloading code.
>   - It does not have to be used together with repo.
>     For example, if I just want revlogs, I can send "revlog path" and
>     preload them. Revlog is not a good example but you get the idea.
>     A real user of this may be remotefilelog's packfiles.
>   - The core only has minimal support code.
>     i.e. "chgcache" won't be everywhere in "mercurial/".
>   - Most chgcache users are expected to be extensions touching random areas.

Thanks, I think I can get what the chgcache is. It's a simple global cache
and its namespace and contents are managed by several upper-level modules
separately. So if we had a repostorage layer now, chgcache would be used
behind the storage layer, right?

BTW, suppose we need chgcache for revlog, how would the cached content tied
with repo path?

> If chg's preloading ability has to be exposed via a "chgrepostorage", it's
> less flexible, and increases the overhead of code touching storage - they
> may have to wrap both chgrepostorage and the original storage class.

That wouldn't be necessary. A storage object could be considered an interface
accessing to data which has the same lifetime as the repo. At the lowest level,
it could provide setcache() and getcache() functions.

> Since I have already moved the most troublesome logic (loading extensions)
> out of localrepository [1]. I'd like to just go ahead with a chgpreloadrepo
> class inherited from localrepository with some key functions disabled. In
> that way, it seems easier and better compatible with others.
> 
> [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/093173.html

Do you mean we can go without the baselocalrepostiroy class? Then, I think
it's okay to add a few chgcache hacks like recordrepopath() to localrepository.