chg and uisetup

Jun Wu quark at
Fri Jul 8 06:31:37 EDT 2016

The current chg design runs uiseutp/extsetup of other extensions once per
process and that leads to a common pitfall:

  If a developer takes a reference to ui in uisetup, or tests some configs
  and do wrapfunctions in uisetup, these effects are permanent to the chg
  server and the extension may use a stale config forever
  (if they do not take the config from reposetup).

This is to discuss how to solve the above issue. I think we have mainly 2

1. Do not run uisetup / extsetup before forking

   Assume that:
   1. importing (do not run *setup) an extension module is side-effect free
   2. ui/extsetups are fast (seems true by my benchmark)

   We can just import all potentially needed modules in chgserver.

   This looks like a big arch change, and a big step backward because a lot
   of code can be removed, and is against the preforking model. But it is
   doable within the current framework by providing a blank hgrc, and call
   extensions.load() during chgserver startup. The command would be like:

      cd /; HGRCPATH=blankhgrc hg serve ... --pre-import some-hgext/*.py

   The result will be:

      - guaranteed one server per user, minimized server processes
      - behave the same with hg, as long as the assumption 1 is true
      - confighash is no longer necessary (mtimehash still needed)
      - chg client argv passing hasck is no longer necessary
      - validate only needs to check mtimehash
      - reposetup issue can be easily solved, by chdir
      - srcui.walkconfig hack is no longer necessary
      - other solutions in this discussion are unnecessary

   Personally I like this approach, and want a simpler chg, although it
   means reverting a lot of my previous efforts. Not supporting preforking
   is fine as I think a more correct approach is another single process
   dedicated to answer some defined questions, like partialmatch etc. The
   dedicated caching daemon should not be easily killed by ^C.

   Convincing an extension to not have side effects outside *setup is also
   easier than not taking a ui reference in *setup.

   If we want to try preforking model, this can also be implemented as an
   option (may need some static config files that the client can read).

2. An official way to let extensions tell chg what needed to be hashed

   Consider all kinds of flexibility needed, I think extensions should have
   something like hashfunc(ui) and register it to chg (as we don't want
   another top-level function):

     def hashfunc(ui):
         return a-string

     def uisetup(ui):
         chgserver.registerhashfunc(extname, hashfunc)

   This is less appealing since extensions have to be aware of chg.

What do you think?

More information about the Mercurial-devel mailing list