[PATCH 2 of 2 v2] tests: rename syshg to testrepohg

[Adam Simpkins]

On Jun 30, Matt Harbison wrote:
> On Fri, 30 Jun 2017 22:22:42 -0400, Adam Simpkins <simpkins at fb.com> wrote:
> 
> >On Jun 30, Matt Harbison wrote:
> >>On Fri, 30 Jun 2017 21:21:11 -0400, Adam Simpkins
> >><simpkins at fb.com> wrote:
> >>
> >>># HG changeset patch
> >>># User Adam Simpkins <simpkins at fb.com>
> >>># Date 1498871800 25200
> >>>#      Fri Jun 30 18:16:40 2017 -0700
> >>># Node ID 8fbab57de1136dbbb8397959785945255352d200
> >>># Parent  bc44cbbfd13d88fbd2d10a7eed7c0ea26002c87c
> >>>tests: rename syshg to testrepohg
> >>>
> >>>Rename the syshg function to testrepohg, to more accurately
> >>>reflect what this
> >>>function does now.  This function runs hg for interacting with the
> >>>$TESTDIR/..
> >>>repository.  This intelligently decides whether to use the local
> >>>hg script or
> >>>the system hg installation.
> >>
> >>This fixes the problem in V1, but reintroduces the obsolete markers
> >>line.  Oddly, only in test-check-commit.t, out of all of the *check*
> >>tests.
> >>
> >>Any diagnostics you'd like me to collect?
> >
> >Hmm, I suspect that's because the first patch in this set restored the
> >default behavior of trying the local hg script first, and only using
> >the system hg if that fails, as Yuya requested.
> >
> >Using the local hg script "works" in this case (has a 0 exit status),
> >but prints a warnings since the settings aren't quite right.
> >
> >Personally I think the right behavior here is to default to the system
> >hg first, and only use the local hg script if that fails.  The system
> >hg command is almost certainly the right thing to use--if we try using
> >the local hg script with the test's HGRCPATH settings we are much more
> >likely to be using the wrong settings for this repository.
> 
> Since I've got all of my extensions enabled in my user level config
> file, I can't get my mind around why local vs system hg would matter
> (for me).
> 
> Is it possible to unset HGRCPATH, so that the system default configs
> are used?  FWIW, I generally keep my system hg within a few releases
> of the latest.  That way I can do updates without the code modifying
> itself on the fly.  Otherwise, I'm using the local hg.

That's effectively what the syshg version is trying to do:
it tries to invoke "hg" as closely as possible to how you would invoke
it manually.  It uses the same HGRCPATH settings you do, and the same
version of hg that you get from your PATH.

I think just doing this behavior by default is the right approach, and
only falling back to the local hg script if the hg from $PATH is so
outdated that we cannot use it.  This behavior should do the right
thing for pretty much everyone I believe.

The v1 and v2 versions of my patch reverted the behavior to use the
local hg script as long as it worked, but they were a bit too lenient
with how they detected if it worked or not.  In your case they decided
it was good enough to use even though it printed warnings in some cases.
The v3 version of the patch goes back to using the system hg by
default, and only falling back to the local hg as a last resort if
that is completely unusable.

-- 
Adam Simpkins
simpkins at fb.com