store: implement fncache basic path encoding in C (This is not yet enabled; it will be turned on in a followup patch.) The path encoding performed by fncache is complex and (perhaps surprisingly) slow enough to negatively affect the overall performance of Mercurial. For a short path (< 120 bytes), the Python code can be reduced to a fairly tractable state machine that either determines that nothing needs to be done in a single pass, or performs the encoding in a second pass. For longer paths, we avoid the more complicated hashed encoding scheme for now, and fall back to Python. Raw performance: I measured in a repo containing 150,000 files in its tip manifest, with a median path name length of 57 bytes, and 95th percentile of 96 bytes. In this repo, the Python code takes 3.1 seconds to encode all path names, while the hybrid C-and-Python code (called from Python) takes 0.21 seconds, for a speedup of about 14. Across several other large repositories, I've measured the speedup from the C code at between 26x and 40x. For path names above 120 bytes where we must fall back to Python for hashed encoding, the speedup is about 1.7x. Thus absolute performance will depend strongly on the characteristics of a particular repository.

rebase: ensure rebase does not revive extinct revision Here, we exclude hidden changesets from a rebase operation. If we don't, a rewritten version of the hidden changesets will be created by rebase. Those rewritten versions won't be hidden and will likely conflict with other rewriting or revive pruned changeset. Moreover, rewriting hidden revisions will surprise the user. This change would not be necessary if changelog filtering were already in core. But it's fairly cheap and helps to increase the test-suite for such filtering. Once changelog level filtering is added, hidden changes will be automatically excluded or included according to the global --hidden flags. Plain ignoring them is good enough for now.

rebase: remove useless list around repo.revs As repo.revs already returns a list.

rebase: properly handle --collapse when creating obsolescence marker In collapse mode, that content of state is not suitable to compute obsolescence markers. We explicitly pass the resulting revision instead and use it as the successors for all elements of the rebased set.

rebase: allow creation obsolescence relation instead of stripping When obsolescence feature is enabled we now create markers from the rebased set to the resulting set instead of stripping. The "state" mapping built by rebase holds all necessary data. Changesets "deleted" by the rebase are marked "succeeded" by the changeset they would be rebased one. That the best guess of "successors" we have. Getting a successors as meaningful as possible is important for automatic resolution of obsolescence troubles. In other word, emptied changeset will looks collapsed with their former parents. (see "empty changeset" section of the test if you are still confused)

rebase: extract final changesets cleanup logic in a dedicated function At the end of the rebase, rebased changesets are currently stripped. This behavior will be eventually dropped in favor of obsolescence marker creation. The main rebase function is already big and branchy enough. This changeset move the clean-up logic in a dedicated function before we make it more complex.