merge: remove uses of manifest.matches This gets rid of the manifest.matches calls in merge.py in favor of the new api. This is part of getting rid of manifest.matches since it is O(manifest).

copies: remove use of manifest.matches Convert the existing use of manifest.matches to use the new api. This is part of getting rid of manifest.matches, since it is O(manifest).

manifest: add match argument to diff and filesnotin As part of removing manifest.matches (since it is O(manifest)), let's start by adding match arguments to diff and filesnotin. As we'll see in later patches, these are the only flows that actually use matchers, so by moving the matching into the actual functions, other manifest implementations can make more efficient algorithsm. For instance, this will allow treemanifest diff's to only iterate over the files that are different AND meet the match criteria. No consumers are changed in this patches, but the code is fairly easy to verify visually. Future patches will convert consumers to use it. One test was affected because it did not use the kwargs version of the clean parameter.

fileset: drop false function signatures from revs() and status() docs They should be inserted by @predicate helper.

py3: factor out bytechr() function I also changed xrange(127) to range(127) as the number is relatively small.

vfs: use 'vfs' module directly in 'test-clone-uncompressed' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'test-filecache' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'test-parseindex' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'test-lock' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'contrib/undumprevlog' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'hgext.largefile' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'hgext.convert' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'hgext.transplant' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'hgext.shelve' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'hgext.mq' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.unionrepo' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.statichttprepo' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.bundlerepo' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.debugcommand' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.simplemerge' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.cmdutil' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.subrepo' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.archival' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.store' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.patch' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.repair' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

vfs: use 'vfs' module directly in 'mercurial.localrepo' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.

chg: forward user-defined signals SIGUSR1 and SIGUSR2 are reserved for user-defined behaviors. They may be redefined by an hg extension [1], but cannot be easily redefined for chg. Since the default behavior (kill) is not that useful for chg, let's forward them to hg, hoping it got redefined there and could be more useful. [1] https://bitbucket.org/facebook/hg-experimental/commits/e7c883a465

chg: document why we send SIGHUP and SIGINT to process group This makes the code more consistent - other signals are documented.

tests: make test-shelve.t timing-independent It was sometimes taking 2s for me (not the "1s" the test expected).

tests: make run-tests.py run on Python 3 again

rebase: move actual rebase into a single transaction 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.