json: implement {manifest} template Property naming was borrowed from `hg files -Tjson`. We omit branch because, again, representation of branches in this template is wonky.

json: implement {shortlog} and {changelog} templates These are the same dispatch function under the hood. The only difference is the default number of entries to render and the template to use. So it makes sense to use a shared template. Format for {changelistentry} is similar to {changeset}. However, there are differences to argument names and their values preventing us from (easily) using the same template. (Perhaps there is room to consolidate the templates as a follow-up.) We're currently not recording some data in {changelistentry} that exists in {changeset}. This includes the branch name. This should be added in a follow-up. For now, something is better than nothing.

help: populate template functions via docstrings We do this for revsets, template keywrods, and template filters. Now we do it for template functions as well.

templater: add consistent docstrings to functions The content of "hg help templating" is largely derived from docstrings on functions providing functionality. Template functions are the long holdout. Prepare for generating them dynamically by defining docstrings for all template functions. There are numerous ways these docs could be improved. Right now, the help output simply shows function names and arguments. So literally any accurate data is better than what is there now.

changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.

changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.

changeset_printer: handle workingctx in _meaningful_parentrevs()

scmutil: add function to help handling workingctx in arithmetic operation It's unfortunate that workingctx revision is None, which doesn't work well in arithmetic operation or comparison. This function is trivial but will be used in several places.

tests: handle deleted .hg directory (git 2.2.0 and higher) (issue4585) In git 2.2.0 and higher, removing files and directories is changed: removing an object that does not exist returns success rather than failure. As a result, even though .hg/hgrc does not exist, success is returned and the .hg/ directory is removed. To handle this correctly, use 'rm -rf' to allow successful removing for all git versions. The exact changeset where this was introduced in git: 1054af7d04aef64378d69a0496b45cdbf6a0bef2 wrapper.c: remove/unlink_or_warn: simplify, treat ENOENT as success

hgweb: resurrect <span> tag on diffline to fix rendering in monoblue style It was removed at 606a3bf82e30 as a useless tag, but it is necessary to apply "div.diff pre span" style. http://selenic.com/repo/hg/rev/606a3bf82e30?style=monoblue

merge with stable

encoding: use parsers.asciiupper when available This is used on Windows and Cygwin, and the gains from this are expected to be similar to what was seen in 80f2b63dd83a.

parsers: introduce an asciiupper function

parsers: make _asciilower a generic _asciitransform function We can now pass in whatever table we like. For example, an upcoming patch will introduce asciiupper.

parsers._asciilower: use an explicit return object No functional change, but this will make upcoming patches cleaner.

parsers: factor out most of asciilower into an internal function We're going to reuse this in upcoming patches. The change to Py_ssize_t is necessary because parsers.c doesn't define PY_SSIZE_T_CLEAN. That macro changes the behavior of PyArg_ParseTuple but not PyBytes_GET_SIZE.

manifestv2: add support for writing new manifest format If .hg/requires has 'manifestv2', the manifest will be written using the new format.

manifestv2: add support for reading new manifest format The new manifest format is designed to be smaller, in particular to produce smaller deltas. It stores hashes in binary and puts the hash on a new line (for smaller deltas). It also uses stem compression to save space for long paths. The format has room for metadata, but that's there only for future-proofing. The parser thus accepts any metadata and throws it away. For more information, see http://mercurial.selenic.com/wiki/ManifestV2Plan. The current manifest format doesn't allow an empty filename, so we use an empty filename on the first line to tell a manifest of the new format from the old. Since we still never write manifests in the new format, the added code is unused, but it is tested by test-manifest.py.

manifestv2: set requires at repo creation time While it should be safe to switch to the new manifest format on an existing repo, let's keep it simple for now and make the configuration have any effect only at repo creation time. If the configuration is enabled then (at repo creation), we add an entry to requires and read that instead of the configuration from then on.

test-manifest: extract constants for binary hashes The binary hashes are used quite frequently, so let's extract constants for them so we don't have to repeat binascii.unhexlify() so often.

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.