[PATCH 1 of 4 RFC] chgcache: new experimental extension

[Yuya Nishihara]

On Mon, 13 Feb 2017 10:18:08 -0800, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-02-13 22:46:23 +0900:
> > On Wed, 8 Feb 2017 17:41:01 -0800, Jun Wu wrote:
> > > # HG changeset patch
> > > # User Jun Wu <quark at fb.com>
> > > # Date 1486601732 28800
> > > #      Wed Feb 08 16:55:32 2017 -0800
> > > # Node ID 138f7ba58a70de9610713b8bd55d1ba0ac468fa6
> > > # Parent  a68510b69f413545722c086eaeb840dd5e8305b4
> > > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > > #              hg pull https://bitbucket.org/quark-zju/hg-draft  -r 138f7ba58a70
> > > chgcache: new experimental extension
> > > 
> > > This patch starts a new experimental extension - chgcache, which aims to
> > > make chg stateful and be able to preload repo objects like the changelog,
> > > the dirstate, the obsstore etc.
> > > 
> > > The feature is being developed as a new extension, instead of directly at
> > > core chg, because its APIs and implementation details are still subject to
> > > change.
> > 
> > I don't get why we're starting it as an extension. Can you elaborate?
> > 
> > My random thoughts:
> > 
> >  a) because the feature is unstable
> >     => could be gated by config knob.
> >  b) for faster experiment of ideas
> >     => out-of-core extension might be better.
> >  c) to dump the whole implementation in case it turns out bad
> >     => maybe.
> 
> I actually prefer doing it in core directly, but I don't have enough
> confidence on the final API. I guess it's fine as the users of the API would
> be limited.
> 
> Another slight concern is putting all the API code in chgserver.py will make
> it much longer - probably also fine as long as different sections are
> separated by comments clearly.

Sounds like we want a new chgcache module (not an extension.)