revert: prefix variable names for dirstate status with "ds" As we are going to introduce status again other revision we needs to distinguish between data from dirstate status and the other one. We prefix the existing data with "ds" to highlight this.

revert: move manifest membership condition outside of the loop Currently, revset is using information from dirstate status and alter its behavior whenever the file exist in the target manifest or not. This tests are done a big for loop. We move this member ship testing outside of the loop and simplifies associates data structure. This is a step toward a cleaner implementation of revert based on status.

histedit: add "roll" command to fold commit data and drop message (issue4256) This new histedit command (short for "rollup") is a variant of "fold" akin to "hg amend" for working copy: it accumulates changes without interrupting the user and asking for an updated commit message.

repoview: cache hidden changesets Use the introduced caching infrastructure to cache hidden changesets. We crosscheck if the content of the cache unless experimental.verifyhiddencache is set to False. This will be removed in the future. Without crosschecking the caches speed ups hg status and other commands: without caching: $ time hg status hg status 0.72s user 0.20s system 100% cpu 0.917 total with caching $ time hg status hg status 0.49s user 0.15s system 100% cpu 0.645 total

repoview: add caching bits Add a caching infrastructure to cache hidden changesets. The cache tries to read the cache lazily and falls back to recomputing if no wlock can be obtain. To validate the cache we store a sha of the obstore content and repo heads in the beginning of the cache which we check every request.

repoview: split _gethiddenblockers Split up _gethiddenblockers into two categories: (1) "static' blockers that solely rely on the contents of obstore and are visible children of hidden changsets. (2) "dynamic" blockers, appearing by having wd parents, bookmarks or tags pointing to hidden changesets. We assume that (1) doesn't change often and can be easily cached with a good invalidation strategy. (2) change often, but barely produce blockers, so we can recompute them if necessary.

repoview: use set for blockers Blockers should be unique but tags and bookmarks could point to the same rev, therefore use a set to ensure that we don't have duplicates.