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

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-03-05 18:11:12 +0900:
> 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?

Yes. repostorage will use chgcache, but repostorage is not the only way to
use chgcache.

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

Its key will be "revlog path" instead of "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.

I agree. What I'm trying to implement is the "[gs]etcache" part, relatively
separate from the storage layer.

> > 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.

I got the general idea. Let me try again.