test-manifest: create constant for empty manifest For symmetry with manifest v2, once we add that, let's extract a constant for the empty v1 manifest.

patchbomb: factor out scmutil.revrange() calls This allows us to access the calculated revs in patchbomb() function.

patchbomb: return outgoing revs as a smartset This helps to factor out scmutil.revrange() calls from _getpatches() and _getoutgoing(). In future patches, a smartset will be passed to _getpatches().

templatefilters: add "upper" and "lower" for case conversion Typically it will be used in patchbomb's flag template, which will be implemented by future patches.

repoview: improve compute staticblockers perf Previously we would compute the repoview's static blockers by finding all the children of hidden commits that were not hidden. This was O(number of commits since first hidden change) since 'children' requires walking every commit from tip until the first hidden change. The new algorithm walks all heads down until it sees a public commit. This makes the computation O(number of draft) commits, which is much faster in large repositories with a large number of commits and a low number of drafts. On a large repo with 1000+ obsolete markers and the earliest draft commit around tip~200000, this improves computehidden perf by 200x (2s to 0.01s).

hgweb: add phase to {changeset} template It's pretty surprising phase wasn't part of this template call already. We now expose {phase} to the {changeset} template and we expose this data to JSON. This brings JSON output in line with the output from `hg log -Tjson`. The lone exception is hweb doesn't print the numeric rev. As has been stated previously, I don't believe hgweb should be exposing these unstable identifiers. (We can add them later if we really want them.) There is still work to bring hgweb in parity with --verbose and --debug output from the CLI.

json: implement {changeset} template Output only contains basic changeset information for the moment. The format is compatible with `hg log -Tjson`.

test-hgweb-json: fix URL for file revision tests Likely a copy and paste fail.

dirstate._normalize: don't construct dirfoldmap if not necessary Constructing the dirfoldmap is expensive, so if there's a hit in the filefoldmap, don't construct the directory foldmap. This helps with cases like 'hg add foo' where foo is already tracked: for a large repository, the operation goes from 1.5 seconds to 1.2 (which is still way too much, but that's a matter for another day.)

dirstate.walk: don't keep track of normalized files in parallel Rev 2bb13f2b778c changed the semantics of the work list to store (normalized, non-normalized) pairs. All the tuple creation and destruction hurts perf: on a large repo on OS X, 'hg status' went from 3.62 seconds to 3.78. It also is unnecessary in most cases: - it is clearly unnecessary on case-sensitive filesystems. - it is also unnecessary when filenames have been read off of disk rather than being supplied by the user. The only case where the non-normalized case is required at all is when the file is unknown. To eliminate most of the perf cost, keep trace of whether the directory needs to be normalized at all with a boolean called 'alreadynormed'. Pay the cost of directory normalization only when necessary. For the above large repo, 'hg status' goes to 3.63 seconds.