[PATCH 3 of 3 RFC] chgserve: preimport enabled extensions

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2016-10-04 00:29:09 +0900:
> On Mon, 3 Oct 2016 15:39:24 +0100, Jun Wu wrote:
> > Excerpts from Yuya Nishihara's message of 2016-10-03 21:59:02 +0900:
> > > Regarding this, I was thinking about 'extensions.<name>:enabled' syntax so
> > > users (or sysadmins) can define a set of conditionally-enabled extensions
> > > globally.
> > > 
> > >   [extensions]
> > >   rebase =
> > >   topic = /path/to/topic.py
> > >   topic:enabled = False
> > > 
> > > chg daemon will import all extensions listed in ~/.hgrc. And if :enabled = True
> > > is flagged by repo/.hg/hgrc, ui/reposetup() will be run.
> > 
> > This may make the implementation more complex and fragile. One area that chg
> > currently cannot handle 100% correct is things like "-r bundles", shared
> > repo, or inferrepo - confighash may mismatch forever because of differences
> > between chg's config loading logic and the non-chg one. If that happens, chg
> > may redirect forever.
> 
> Isn't the goal of this series to get rid of the confighash?

Yes. "confighash" will only contain sensitive environment variables like
PYTHONPATH, LD_PRELOAD etc. ui.config won't affect confighash.

> > Because of the above two reasons, I prefer no uisetup for all extensions. It
> > leads to a simpler and safer implementation.
> 
> Yep. No ui/reposetup() in the main server process. My idea is how to tell
> chg server to pre-import extensions which can't be enabled globally.

That has been taken care of in patch 4, which I haven't sent yet. [1]

[1]: https://bitbucket.org/quark-zju/hg-draft/commits/51278775

> > Regarding on reposetup, I'm aware that some repo state like the radix tree
> > index needs to be persistent in memory. In my opinion, it would be better
> > solved by other IPC means, like shared memory or a background daemon
> > speaking some protocol.
> 
> Like memcached in some ways.