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

Yuya Nishihara 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
> fastmanifest:
> 
>   https://bitbucket.org/facebook/hg-experimental/src/be7a54df7b36f7e9ac93ae05b9ff7621e32c089c/fastmanifest/__init__.py?at=default&fileviewer=file-view-default#__init__.py-163

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=!
> pattern).

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 mailing list