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

Yuya Nishihara yuya at tcha.org
Mon Oct 3 11:29:09 EDT 2016


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?

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

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


More information about the Mercurial-devel mailing list