[PATCH 05 of 10] chgserver: add a context manager to learn what to include for confighash
yuya at tcha.org
Thu Jul 7 08:49:01 EDT 2016
On Wed, 6 Jul 2016 16:33:30 +0100, Jun Wu wrote:
> 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
For this particular example, wrapping manifest.rev can be moved to reposetup().
1. extend repo.__class__ to hook repo.manifest
2. extend manifest.__class__ to hook manifest.rev
> 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.
Hmm, but you can't track the access to ui.debugflag without an ugly hack. Only
ui.config*() calls are recorded.
> > > 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.
As long as the section is specific to the extension, the extension can add
its own section to the white/black list.
> 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=!
It sounds like you're urged to reduce the number of chg processes, though
I don't know why it's such important. In that case, I agree the not-to-hash
list isn't acceptable. Also, I don't think your auto-learner can be the
permanent solution since we'll have to fix chg-unfriendly extensions anyway.
Instead, I think you can make the auto-learner extension and enable it as
a temporary way around. The patch 3, [(section, name)] list, seems good to
include in the core.
More information about the Mercurial-devel