"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.
This is a quick fix to make `hg phabread D189` work.
It seems we might want to replace all `r''` to `u''`, and add more
`encoding.*to*` to be more explicit when interacting with `json` module.
Differential Revision: https://phab.mercurial-scm.org/D192
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.
When we changed basematcher.visitdir() in 0ca205268beb (match: make
base matcher return True for visitdir, 2017-07-14), we forgot to add
an override in nevermatcher. This led to tests failing in narrowhg.
As Durham pointed out, it's high time to add unit tests for the
matcher, so this patch also adds a first unit test.
Differential Revision: https://phab.mercurial-scm.org/D151
There's a bug in the (feature !) annotation, and this needs to be resolved
before fixing it. Once fixed, the glob '*/missing' will match the output
'/missing' on non-Windows platforms, consuming the output line and leaving
nothing for the no-windows required line.
I probably should have made (foo !) match only the 'foo' feature, and be ignored
otherwise instead of optional. (re) didn't work here, because the parenthesis
need to be escaped too.
By default, the extension has default sections like fix, feature, perf etc.. This
patch allow user to add support for custom admonition. In order to add a custom
admonition, one needs to have a .hgreleasenotes file inside the repository. All the
custom directive with name specified under the tag [sections] will be
usable by the extension. One important thing to keep in mind is if there exists any
custom admonitions with same key as default then they will override the default ones.
I used this to more quickly track down a failing test-check-config.t issue
in another repo. I thought it might be useful more generally, so I'm sending
it out in case others think it's a worthwhile change.
This was previously landed as 507f16f4aa51 but backed out in a5abaa81fa because
it broke hook mid rebase and caused conflict resolution data loss in the event
of unexpected exceptions. This new version adds the behavior back but behind a
config flag, since the performance improvement is notable in large repositories.
The next patch adds a test covering this config.
The old commit message was:
Previously, rebasing would open several transaction over the course of rebasing
several commits. Opening a transaction can have notable overhead (like copying
the dirstate) which can add up when rebasing many commits.
This patch adds a single large transaction around the actual commit rebase
operation, with a catch for intervention which serializes the current state if
we need to drop back to the terminal for user intervention. Amazingly, almost
all the tests seem to pass.
On large repos with large working copies, this can speed up rebasing 7 commits
by 25%. I'd expect the percentage to be a bit larger for rebasing even more
commits.
There are minor test changes because we're rolling back the entire transaction
during unexpected exceptions instead of just stopping mid-rebase, so there's no
more backup bundle. It also leave an unknown file in the working copy, since our
clean up 'hg update' doesn't delete unknown files.
(grafted from cca36c7f35261b0e31beb226bf361067ef0e06ab)
(grafted from dc497d8705b71503e32e07bd33925c1e42cf9c9a)
Differential Revision: https://phab.mercurial-scm.org/D134
