Before this patch, source filename for msgid in hg.pot file becomes
incorrect, if a function is defined in file A, but detected in dict in
file B,
For example, almost all debug* commands are defined in
debugcommands.py, but hggettext detects them in "table" of
commands.py. Therefore, docstring fragments of debug* commands are
marked as "defined in commands.py" in hg.pot file.
This is serious problem for translation, because the cost to find out
original location of texts increases very much.
Before this patch, explicit --pager=on is unintentionally ignored by
any disabling factor, even if priority of it is less than --pager=on
(e.g. "[ui] paginate = off").
'ssh://' has an exploit that will pass the url blindly to the ssh
command, allowing a malicious person to have a subrepo with
'-oProxyCommand' which could run arbitrary code on a user's machine. In
addition, at least on Windows, a pipe '|' is able to execute arbitrary
commands.
When this happens, let's throw a big abort into the user's face so that
they can inspect what's going on.
'ssh://' has an exploit that will pass the url blindly to the ssh
command, allowing a malicious person to have a subrepo with
'-oProxyCommand' which could run arbitrary code on a user's machine. In
addition, at least on Windows, a pipe '|' is able to execute arbitrary
commands.
When this happens, let's throw a big abort into the user's face so that
they can inspect what's going on.
'ssh://' has an exploit that will pass the url blindly to the ssh
command, allowing a malicious person to have a subrepo with
'-oProxyCommand' which could run arbitrary code on a user's machine. In
addition, at least on Windows, a pipe '|' is able to execute arbitrary
commands.
When this happens, let's throw a big abort into the user's face so that
they can inspect what's going on.
After this patch, README as reST text can be rendered into HTML more
appropriately. This is useful for hosting servers, which render README
file as a part of index HTML of its directory (for example,
Bitbucket).
The test for duplicate flag processors depended on the timestamps
being set in the dirstate to work. If the time between the the
previous failed commit (which would set the timestamp, due to bug
5645) and the attempted commit with the duplicate flag processors was
small enough, it would fail. The failure was caused by a call to
commands.status() early in the commit process. If the dirstate did not
have the timestamp set, it would need to fetch the file content to
compare with. Since two flag processors had been registered, it would
attempted to base64 decode the contents twice, which would of course
fail.
This patch adds a "hg debugrebuilddirstate" to make it deterministic
and also replaces the test case's "hg commit" by simply "hg status",
since that will trigger reading of the contents and thereby use of the
flag processors as noted above.
Differential Revision: https://phab.mercurial-scm.org/D202
The flag processors test for duplicate processors for a single flag
was misleading because the file from the previous test case caused it
to fail (making the "echo 'this should fail' > file" part
irrelevant). Let's remove the leftover from the previous test case to
make it clear that duplicate flag processors results only in a
warning.
Note that duplicate flag processors would have resulted in a failure
(not just a warning) until b319e3173a95 (extensions: catch uisetup and
extsetup failures and don't let them break hg, 2017-06-06). I remember
expressing my concern about ending up with half-loaded extensions. It
would be pretty unfortunate to have double-encoded revlog content
enter a repo, so maybe we should reconsider?
Differential Revision: https://phab.mercurial-scm.org/D201
Invocation of "diff tool.py" in test-extdiff.t tests whether
shellquote() is applied on specified command as expected.
But direct invocation of "*.py" file might cause unexpected result on
Windows according to suffix binding.
For example, starting IDE, showing dialog to choose program to be
used, and so on. In such case, running test-extdiff.t is easily timed
out.
This patch uses intermediate *.bat file on Windows, to avoid such
unexpected result. Naming that intermediate file as "diff tool.bat" is
enough to test applying shellquote().
"diff" command might cause redundant message, "No differences
encountered" on Solaris for example. But suppressing option like "-q"
isn't portable, because POSIX specification doesn't define it.
pdiff script was introduced by f4cba8b2e7b4 to stabilize output of
standard diff command on each platforms.
Before this patch, pdiff script returns 0, even if diff is detected.
This issue doesn't cause failure of tests using it, if it is invoked
via extdiff extension, because extdiff itself examines changes between
specified revisions and decides exit code.
BTW, this patch ignores recursive comparison case, because:
- there is no portable way for current while-read based
implementation to return 1 at detecting changes
- it isn't yet needed to replace direct "diff -r" invocation by
pdiff for portability
We had the first 3 tests in test-profile.t fail because the output
didn't match. I have not yet confirmed that this was because no
samples were collected, but we shouldn't require samples to be
collected for the test to pass either way.
Differential Revision: https://phab.mercurial-scm.org/D199
Our use of SSH has an exploit that will parse the first part of an url
blindly as a hostname. Prior to this set of security patches, a url
with '-oProxyCommand' could run arbitrary code on a user's machine. In
addition, at least on Windows, a pipe '|' can be abused to execute
arbitrary commands in a similar fashion.
We defend against this by checking ssh:// URLs and looking for a
hostname that starts with a - or contains a |.
When this happens, let's throw a big abort into the user's face so
that they can inspect what's going on.
In Pypy 5.6.0, traceback exception classes are not displayed with their full
qualified name.
Instead of displaying mercurial.error.ProgrammingError, Pypy displays
ProgrammingError.
Update the test to support both version.
Pypy 5.6.0 saves cached bytecode files in __pycache__ directory, clean them in
tests to fix loading old test extensions code.
Doing so should also helps for Python3.x migration.
statichttprepo inherits from localrepository. In doing so, it
obtains default implementations of various methods, like wlock().
Before this change, tags cache writing would call repo.wlock().
This failed on statichttprepo due to localrepository's wlock()
looking for an instance attribute that doesn't exist on statichttprepo
(statichttprepo doesn't call localrepository.__init__).
We /could/ define missing attributes until the base wlock() works.
However, a statichttprepo is remote and read-only and can't be
locked. The class already has a lock() that short circuits. So
it makes sense to implement a short-circuited wlock() as well. That
is what this patch does.
LockError is expected to be raised when locking fails. The constructor
takes a number of arguments that are local repository centric. Rather
than rework LockError to not require them (which would not be
appropriate for stable), this commit populates dummy values. I don't
believe they'll ever be seen by the user, as lock failures on
static http repos should be limited to well-defined (and tested)
scenarios. We can and should revisit the LockError type to improve
this.
The initial attempt was to discard cache when appropriate, but it appears
to be error prone. We had to carefully inspect all places where audit() is
called e.g. without actually updating filesystem, before removing files and
directories, etc.
So, this patch disables the cache of audited paths by default, and enables
it only for the following cases:
- short-lived auditor objects
- repo.vfs, repo.svfs, and repo.cachevfs, which are managed directories
and considered sort of append-only (a file/directory would never be
replaced with a symlink)
There would be more cacheable vfs objects (e.g. mq.queue.opener), but I
decided not to inspect all of them in this patch. We can make them cached
later.
Benchmark result:
- using old clone of http://selenic.com/repo/linux-2.6/ (38319 files)
- on tmpfs
- run HGRCPATH=/dev/null hg up -q --time tip && hg up -q null
- try 4 times and take the last three results
original:
real 7.480 secs (user 1.140+22.760 sys 0.150+1.690)
real 8.010 secs (user 1.070+22.280 sys 0.170+2.120)
real 7.470 secs (user 1.120+22.390 sys 0.120+1.910)
clearcache (the other series):
real 7.680 secs (user 1.120+23.420 sys 0.140+1.970)
real 7.670 secs (user 1.110+23.620 sys 0.130+1.810)
real 7.740 secs (user 1.090+23.510 sys 0.160+1.940)
enable cache only for vfs and svfs (this series):
real 8.730 secs (user 1.500+25.190 sys 0.260+2.260)
real 8.750 secs (user 1.490+25.170 sys 0.250+2.340)
real 9.010 secs (user 1.680+25.340 sys 0.280+2.540)
remove cache function at all (for reference):
real 9.620 secs (user 1.440+27.120 sys 0.250+2.980)
real 9.420 secs (user 1.400+26.940 sys 0.320+3.130)
real 9.760 secs (user 1.530+27.270 sys 0.250+2.970)
Since these modules are implicitly imported by policy.importmod(), py2exe
can't track them statically. cffi modules are excluded for now because they
wouldn't be useful in frozen (i.e. CPython) environment.
The only version strings that are changed are the ones baked into the
.pkg - hg's self-reported version string doesn't change, so users will
still see our mostly-pip-compatible version strings.
For reference, the part of our versioning setup that's not PEP440
compatible is the RC releases - those should be .rc0 insted of
-rc. It's too late to change that for the 4.3 cycle, so I'll worry
about fixing that during the 4.4 cycle.
If you're shipping prerelease or rc packages using Munki, you'll
eventually discover that Munki's version comparison logic is not as
good as pip's. In theory we should be able to fix Munki, but it seems
entirely reasonable to produce version strings that sort reasonably
under these conditions. Since the requried logic not brief, add a new
script and some tests of that logic.
A followup change will wire this into the Makefile.
My intent was to only allow Python 3 if the right environment variable
is set (for when people want to use `pip install .` on hg
locally). This fixes the bug in my previous change. I verified that
`python3.6 run-tests.py` still passes the tests that passed before,
and that all tests pass on 2.7 (including our virtualenv-using
installation test).
Differential Revision: https://phab.mercurial-scm.org/D185
When rebasing a changeset X and that changeset becomes empty, we should move
the bookmark on X to rebase destination.
This is a regression caused by the scmutil.cleanupnodes refactoring for
rebase.
The `adjustdest` function calculates the destination of bookmark movement.
It was back-ported from https://phab.mercurial-scm.org/D21. It might be
slightly more powerful than the minimal requirement to solve this issue.
For example, it's impossible for a merge changeset to become empty while any
of its ancestors does not become empty, but the code could handle that case.
Since the code is reasonably short and clean, and helps the upcoming D21
series, I'd like to check-in `adjustdest` now.
Thanks Martin von Zweigbergk for spotting corner cases (-k and descendant
with bookmarks) in this area!
Modern pip can detect supported Python versions (which we now
declare), and pull down a reasonable release. This trick was suggested
in http://bit.ly/pycon2017-build-bridges, and seems like a good
defensive maneuver so that when we want to move to Python 3 it's
less risky for existing users.
This moves the version-check logic after defining our printf function
so we can print more informative messages.
I think we should probably backport this to 4.2 as well, and do one
more release there that explicitly declares 2.6 support. That way
anyone stuck on Python 2.6 will end up getting the right hg if they
use a modern pip to install. Users can still use `python setup.py`
incantations to attempt installing Mercurial on unsupported Pythons,
including 3.5 and 3.6.
A followup change will switch to only doing our own
Python-version-check logic if we're not being installed by a
reasonable pip.
5ba3f753c9b1 introduced a use of 'hg revert --no-backup' which is
currently broken. Rather than try and do a fix on the (complicated)
revert code during the freeze, let's just give up on this test under
Python 3 until later. Once we do fix things, the test ratchet script
will re-enable it.
