[PATCH 05 of 10] chgserver: add a context manager to learn what to include for confighash
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
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=!
More information about the Mercurial-devel