tests: fix test-check-commit.t when all commits are public
I'm 99% sure this is a portable use of /bin/[, and it seems to fix the
issue I noticed on the buildbot on my machine.
import: fix crash on --exact check of empty commit (
issue5702)
tests: mark test-check-interfaces.py as requiring a repo
This was failing our 4.6rc1 build like this:
mercurial.error.RepoError: repository /tmp/build-debs.zMTRhC/src-4.6rc1 not found
Differential Revision: https://phab.mercurial-scm.org/D3425
sshpeer: reflect actual command activity one handshake
The output from devel-peer-request is expected to give data about request and
roundtrip done to the server. Changeset
a9cffd14aa04 changed some of that by
grouping hello and between commands call. However, the old sequence of command
was "emulated" in sshpeer.
Update the sshpeer to reflect this grouping of commands and update the tests
that use it.
tests: drop a useless glob in test-infinite-bundlestore.t
With the previous breakage tamed, the lack of test output difference was causing
the test runner to report "no result code from test" because of this glob.
infinitepush: ensure fileindex bookmarks use '/' separators (
issue5840)
After loading up with status messages, I noticed that the subsequent matcher was
rejecting 'scratch\mybranch' on Windows. No bookmarks were reported back, and
the tests subsequently failed. I did a search for 'match', and nothing else
looks like it needs to be fixed up, but someone who understands this code should
also take a look.
I also tried setting `infinitepush.branchpattern=re:scratch\\.*` in
library-infinitepush.sh without this change, but that didn't work. Still,
should we ban '\' in these bookmarks to avoid confusion? I thought I saw code
that sandwiches a pattern between 're:^' and '.*', so perhaps regex characters
will need special care?
I also noticed comments in externalbundlestore.{read,write} that it won't work
on Windows because of opening an open file. But I don't see a test failure, so
this may lack test coverage.
interfaceutil: module to stub out zope.interface
The startup time of `hg` increased during the 4.6 development cycle. A
cause of that was importing more modules and doing more work at module
import time.
The import of zope.interface and the declaring of various interfaces
is partially responsible for the startup time regression.
Our current usage of zope.interface doesn't do much at run time: we are
merely declaring interfaces and stating that certain types implement
various interfaces. Core Mercurial is not (yet) using of any of
zope.interface features that actually require that interface plumbing be
defined. The only place we actually need the interface metadata is in
test-check-interfaces.py.
This commit establishes a new interfaceutil module. It exposes the subset
of the zope.interface API that we currently use. By default, the APIs
no-op. But if an environment variable is set, we export the real
zope.interface APIs.
Existing importers of zope.interface have been converted to use the new
module. test-check-interfaces.py has been updated to define the
environment variable so the real zope.interface is used.
The net effect of this change is we stop importing 9 zope.interface.*
modules and we no longer perform interface bookkeeping when registering
interfaces.
On my i7-6700K on Linux, a shell loop that runs `hg log -r .` 300 times
on a repo with 1 commit shows a significant CPU time improvement
(average of 4 runs):
4.5: 14.814s
before: 19.028s
after: 16.945s
And with `run-tests.py -j10` (single run):
4.5: ~3100s (~51.7m)
before: ~4450s (~74.2m)
after: ~3980s (~66.3m)
So this claws back about half of the regressions in 4.6.
Differential Revision: https://phab.mercurial-scm.org/D3419
test-fix: normalize precision of mtime copied by 'cp -p'
Appears that MSYS cp only copies mtime in seconds.
Added signature for changeset
1ec874717d8a
Added tag 4.6rc1 for changeset
1ec874717d8a
diffhelper: rename module to avoid conflicts with ancient C module (
issue5846)
Historically we had had C extensions in mercurial/, which shadows the pure
Python modules of the same name forever unless we do clean build/install.
I'm sloppy to think about new name, so just dropped the "s".
diffhelpers: backport
9e40bc4c1bde from C implementation
9e40bc4c1bde just says "harden testhunk." I don't think this would be
the case, but it makes some sense to avoid negative index.