[PATCH 3 of 3] test-progress: disable mocking-time tests on chg
quark at fb.com
Sat Apr 9 16:32:51 EDT 2016
On 04/09/2016 09:01 AM, Yuya Nishihara wrote:
> I've tried HGMOCKTIME, but the problem seemed not that simple, and I
> stopped investigation as it wouldn't be worth making this test pass on chg.
Yep. I had tried that (before the sprint) as well. It seems it solves some
problem but not all. Therefore I'm okay with just skipping them.
(This is not important anyway. I want to discuss the chg checker script below)
> I don't follow the context behind this patch, but some of the problems
> detected by _chgcompatcheck would happen on plain command server. That
> might justify moving chgserver._configsections somewhere else.
> However, the patch seems overly complicated compared to the benefit
> provided by it.
My V1 patch is a standalone check-chg-compat script:
marmoute has rejected that one telling me I should use devel-warn on IRC.
He marked the patch as "Change Requested" without replying the mail though.
I somehow agree that we may want devel-warn eventually but it is hard to
do now because:
1. devel-warn is enabled for all tests, which means to enable it, we have
to fix all problematic before the devel-warn patch. To fix all extensions,
we have to get the whitelist API refactoring.
2. devel-warn in extensions.loadall() does not work well with chg because they
are only printed once if all extensions are loaded without issues.
3. It cannot be used directly to test third party extensions without side
effect of an hg command.
4. It still looks a bit weird hacking os.environ etc.
Therefore, I think a standalone checker script is the way to go for now because:
1. It allows us to fix problematic extensions one by one instead of fixing
them all the once.
2. It does not pollute core files like "extensions.py".
3. It's easy to reuse the script to check third party extension projects,
just run something like "check-chg-compat.py fb-hgext/*.py".
What do you think?
More information about the Mercurial-devel