[PATCH 3 of 3 RFC] chgserve: preimport enabled extensions
Yuya Nishihara
yuya at tcha.org
Mon Oct 3 15:29:09 UTC 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