Update the code to correctly anchor the expression on the end of the name, to
require that the entire name match this expression. It was already anchored at
the start by using re.match(), but this does not anchor it at the end.
The 4.2 release introduces a regression regarding the behavior of rebase with
some hook failures. We add the tests from the bug report from Henrik Stuart to
our test base to prevent further regression on this.
Having a single transaction for rebase means the whole transaction gets rolled back
on error. To work around this a small hack has been added to detect merge
conflict and commit the work done so far before exiting. This hack works because
there is nothing transaction related going on during the merge phase.
However, if a hook blocks the rebase to create a changeset, it is too late to commit the
work done in the transaction before the problematic changeset was created. This
leads to the whole rebase so far being rolled back. Losing merge resolution and
other work in the process. (note: rebase state will be fully lost too).
Since issue5610 is a pretty serious regression and the next stable release is a
couple day away, we are taking the backout route until we can figure out
something better to do.
In the process of fixing issue5610 in 4.2.2, we are trying to backout
507f16f4aa51. This changeset is making changes that depend on 507f16f4aa51,
so we need to back it out first.
Since issue5610 is pretty serious regression and the next stable release is a
couple of days away, we are taking the backout route until we can figure out
something better to do.
As part of using `hg show` in my daily workflow, I've found it slightly
annoying to have to type full view names, complete with a space. I've
locally registered an alias for "swork = show work."
I think others will have this same complaint and could benefit from
some automation to streamline the creation of aliases. So, this
commit introduces a config option that allows `hg show` views to be
automatically aliased using a given prefix. e.g. a value of "s"
will automatically register "swork" and "sbookmarks." Multiple
values can be given for ultimate flexibility. This arguably isn't
needed now. But since we don't register aliases if there will be
a collision and we're bound to have a collision, it makes sense to
allow multiple prefixes so specific views can avoid collisions by
using different prefixes.
Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
Now that the default value is also converted we can use a human readable version
for it. This will be useful if we start to automatically display the default
config value in various place.
Extensions can have a 'configtable' mapping and use
'registrar.configitem(table)' to retrieve the registration function.
This behave in the same way as the other way for extensions to register new
items (commands, colors, etc).
We simplify the unstable computation code, skipping the expensive creation of
changectx object. We focus on efficient set operation and revnumber centric
functions.
In my mercurial development repository, this provides a 3x speedup to the
function:
before: 5.319 ms
after: 1.844 ms
repo details:
total changesets: 40886
obsolete changesets: 7756
mutable (not obsolete): 293
unstable: 30
Update the syshgenv function to attempt to completely restore the original
environment, rather than only updating a few specific variables. run_tests.py
now generates a shell script that can be used to restore the original
environment, and syshgenv sources it.
This is a bit more complicated than the previous code, but should do a better
job of running the system hg in the correct environment.
I've tested it on Linux using python 2.x, but let me know if it causes issues
in other environments. I'm not terribly familiar with how the tests get run on
Windows, for instance, and how the environment needs to be updated there.
Ancient hg does not have "hg files" so test-check-*.t will fail with
"unknown command 'files'":
$ hg files
hg: unknown command 'files'
$ hg --version
Mercurial Distributed SCM (version 2.6.2)
Test "hg files" and give up using syshg if it does not have "files" command.
Most test scripts use "hg" to interact with a temporary test repository.
However a few tests also want to run hg commands to interact with the local
repository containing the mercurial source code. Notably, many of the
test-check-* tests want to check local files and commit messages.
These tests were previously using the version of hg being tested to query the
source repository. However, this will fail if the source repository requires
extensions or other settings not supported by the version of mercurial being
tested. The source repository was typically initially cloned using the system
hg installation, so we should use the system hg installation to query it.
There was already a helpers-testrepo.sh script designed to help cope with
different requirements for the source repository versus the test repositories.
However, it only handled the evolve extension. This new behavior works with
any extensions that are different between the system installation and the test
installation.
When running the tests, define ORIG_PATH and ORIG_PYTHONPATH environment
variables that contain the original contents of PATH and PYTHONPATH, before
they were modified by run-tests.py
This will make it possible for tests to refer to the original contents of these
variables if necessary. In particular, this is necessary for invoking the
correct version of hg for examining the local repository (the mercurial
repository itself, not the temporary test repositories). Various tests examine
the local repository to check the file lists and contents of commit messages.
Add a findhg() function that tries to be smarter about figuring out how to run
hg for examining the local repository. It first tries running "hg" from the
user's PATH, with the default HGRCPATH settings intact, but with HGPLAIN
enabled. This will generally use the same version of mercurial and the same
settings used to originally clone the repository, and should have a higher
chance of working successfully than trying to run the hg script from the local
repository. If that fails findhg() falls back to the existing behavior of
running the local hg script.
Replace the runhg() function with an hgcommand helper class. hgcommand has as
run() function similar to runhg(), but no longer requires the caller to pass in
the exact path to python and the hg script, and the environment settings for
invoking hg.
For now this diff contains no behavior changes, but in the future this will
make it easier for the hgcommand helper class to more intelligently figure out
the proper way to invoke hg.
Add a helper function to compute the environment used for invoking mercurial,
rather than doing this computation entirely at global scope. This will make it
easier to do some subsequent refactoring.
Update the runcmd() helper function so it also returns the process exit status.
This allows callers to more definitively determine if a command failed, rather
than testing only for the presence of data on stderr.
I don't expect this to have any behavioral changes for now: the commands
invoked by setup generally should print data on stderr if and only if they
failed.
If running hg fails, exit the setup script unsuccessfully, rather than
proceeding to use a bogus version of "+0-". Using an invalid version number
causes various tests to fail later. Failing early makes it easier to identify
the source of the problem.
It is currently easy for setup.py to fail this way since it sets HGRCPTH to the
empty string before running "hg", which may often disable extensions necessary
to interact with the local repository.
There are cases in opts handling in debugcommands.py where we don't need to
convert opts keys back to bytes as there are some handful cases and no other
function using opts value. Using r'', we prevent the transformer to add
a b'' which will keep the value str.
