[PATCH 3 of 3] test-progress: disable mocking-time tests on chg

Yuya Nishihara yuya at tcha.org
Sun Apr 10 06:57:47 EDT 2016


On Sat, 9 Apr 2016 21:32:51 +0100, Jun Wu wrote:
> On 04/09/2016 09:01 AM, Yuya Nishihara wrote:
> > 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:
> http://patchwork.serpentine.com/patch/14230/
> 
> 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?

I tend to agree with marmoute in that devel-warn would be nicer, but that
would be true only if the implementation were clean. As far as I can guess
from your new patch, it would be hard to avoid dirty hacks such as monkey-
patching core functions.

So, I think a standalone script is good start.


More information about the Mercurial-devel mailing list