[PATCH 05 of 10] chgserver: add a context manager to learn what to include for confighash

Jun Wu quark at fb.com
Wed Jul 6 11:33:30 EDT 2016


Excerpts from Yuya Nishihara's message of 2016-07-07 00:05:06 +0900:
> Do they have significant differences in non-core configs other than
> "extensions" section?

They are mainly about new experimental extension features.
Most of them work fine with chg. The one that does not work well is
fastmanifest:

  https://bitbucket.org/facebook/hg-experimental/src/be7a54df7b36f7e9ac93ae05b9ff7621e32c089c/fastmanifest/__init__.py?at=default&fileviewer=file-view-default#__init__.py-163

It basically keeps a ui object in all kinds of its objects, and down in the
stack the ui object is used to do debugflag test or so. As said, I believed
this is not a good pattern and tried to fix them but the codebase is so
large and I gave up after a few hours.

The developer wants to use --debug to toggle debug output so they should be
able to tell chg to hash ui.debugflag, but not other ui config items.

> > About whitelist vs blacklist, I think it's less important. I prefer the
> > current situation.
> 
> It defines the default behavior of chg, whether or not chg is permissive for
> third-party extensions which process their config values in undesired way.
> IMHO it's important property of chg.

But as I said, my main concern about listing what *not* to hash is
unnecessary processes. The list will also be unfriendly for extensions to
change (if they need to) since all extensions must agree together, only that
can a section be added, which is practically impossible.

Internally, one of our testing infra's senior engineers feels annoyed when
he runs a few hg commands and get 4 or 5 chg processes. I think it's very
important to optimize the number of server processes. (Therefore the
blackbox filename series to replace the --config extensions.blackbox=!
pattern).


More information about the Mercurial-devel mailing list