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

Jun Wu quark at fb.com
Wed Mar 1 20:38:44 UTC 2017


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.

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.

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


More information about the Mercurial-devel mailing list