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