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.

merge stable heads

Added signature for changeset 1ec874717d8a

Added tag 4.6rc1 for changeset 1ec874717d8a

internals: correct capitalization of 'compression' stream level parameter

test-check-code: prevent from adding Python modules shadowed by ancient C

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.

version: make parser more robust for rc variants and ill-formed strings

phabricator: specify some metadata compatibly with arc Differential Revision: https://phab.mercurial-scm.org/D3414

diff: restore original color scheme for worddiff I'm not young. "red dim" is nearly invisible, and "red" vs "red dim" is too subtle to see difference. And, "underline" is necessary to highlight whitespace changes.

test-fix: fix use of 'f --newer' to check that foo.whole is not updated Here we want to assert not 'mtime(foo.whole.orig) < mtime(foo.whole)'. The condition has to be inverted since 'f --newer' says "newer" if the mtimes match. Alternatively, we could insert 'sleep 2' before 'cp' to ensure that foo.whole.orig is newer than foo.whole, but a fewer sleeps should be better.

context: translate FilteredIndex/LookupError at repo[changeid] (API) This partially backs out ecd3f6909184. It seems layering violation for repo[changeid] to raise storage-level exceptions transparently. Otherwise, we would have to rewrite callers to catch all of them. try: repo[rev_or_node] except (error.RepoLookupError, error.FilteredIndexError, error.FilteredLookupError): pass This would also fix filectx._changectx(), which catches FilteredRepoLookupError to fall back to the unfiltered path.

inifinitepush: fix filebundlestore to close file

notify: only notify for non-filtered revision This should fix issue5821 for hook targeting individual revision.

notify: access the initial revision on an unfiltered repository (issue5821) This should avoid crash when the first revision pushed end up being hidden.

notify: use changelog API to iterate over revision number (issue5821) This will avoid iterating over filtered revision.

infinitepush: open files in binary mode This fixes the scary looking abort in test-infinitepush-ci.t when unbundling: --- tests/test-infinitepush-ci.t +++ tests/test-infinitepush-ci.t.err @@ -84,15 +84,12 @@ $ hg unbundle .hg/scratchbranches/filebundlestore/a4/c2/a4c202c147a9c4bb91bbadb56321fc5f3950f7f2 adding changesets - adding manifests - adding file changes - added 1 changesets with 1 changes to 1 files - new changesets 6cb0989601f1 - (run 'hg update' to get a working copy) - - $ hg glog - o 1:6cb0989601f1 added a - | public + transaction abort! + rollback completed + abort: stream ended unexpectedly (got 68 bytes, expected 218759168) + [255] + + $ hg glog @ 0:67145f466344 initialcommit public This was found by grepping for '"r', "'r", '"w' and "'w" after manually creating a bundle from the same revision, diffing against the corrupt one, and seeing CRs sprinkled around. Sadly, the missing bookmarks are still a problem in the two remaining test failures.

tests: stabilize test-fix.t for Windows

Added signature for changeset ed5448edcbfa

Added tag 4.6rc0 for changeset ed5448edcbfa

merge with default to begin 4.6 freeze # no-check-commit because of many vendored packages

rebase: introduce support for automatically rebasing orphan changes _destautorebase(SRC) is based on the _destrestack(SRC) revset from fbamend. The supporting _possibledestination function is extracted from evolve, with minor cleanups. We've considered some alternatives here: * This change, but with --auto as the flag name. We're hedging our bets on this a little in this change so that if this ends up being the wrong direction we haven't burned the valauble --auto name on rebase. * --destination auto: I've got reservations about the discoverability of this, and we don't currently have a good story for a revset alias of sorts that changes behavior depending on the context in which it's used. * A "rebase presets" feature, where we could use the currently-an-error positional argument space for the rebase command to define presets, so that users could define a 'linearize' preset that specifies --revision='orphan()-obsolete()' and --dest=_destautoorphanrebase(SRC). Personally, I find the third option somewhat appealing, but am hesitant to "spend" the functionality space of positional arguments to the rebase command. We should revisit the way we expose this functionality sometime in the 4.7 cycle once we've had a chance to vet the implementation of the functionality. Differential Revision: https://phab.mercurial-scm.org/D2668