templatekw: introduce showlatesttags() to handle {latesttag} keywords The keywords {changes}, {distance} and {tag} will be available on a future template method that will allow pattern matching against tag names. For consistency, these should be available on the existing {latesttag} keyword as well. I debated whether or not to add {tag} instead of just continuing with the existing {latesttag}. But it seems clearer not to have the same name for two distinct things (a list in the LHS of %, and an individual tag value on the right). The value of latesttags[0] is the date of commit for the cset to which the tag is applied (i.e. not the date the tag was applied), and therefore isn't made visible because it doesn't seem interesting. It appears that this is merely an internal implementation detail for sorting csets in a stable manner when there are different branches.

templatekw: factor out the changessincetag calculation to a private method This will be reused in the next patch.

templatekw: allow getlatesttags() to match a specific tag pattern This will allow the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It will be exposed in a future patch. It's unfortunate that the original 'latesttags' cache can't be used to determine the proper values, but it isn't fully populated for the entire repo. For example, the {latesttagdistance} keyword on the Mecurial repo builds the cache up back to the revision for 1.4. If the pattern was 're:^0\.\d$', that wouldn't be in the cache. Maybe this can be optimized some other way, but for now, this is the simpliest implementation.

util: extract stringmatcher() from revset This is used to match against tags, bookmarks, etc in revsets. It will be used in a future patch to do the same tag matching in templater.

util.chunkbuffer: avoid extra mutations when reading partial chunks Previously, a read(N) where N was less than the length of the first available chunk would mutate the deque instance twice and allocate a new str from the slice of the existing chunk. Profiling drawed my attention to these as a potential hot spot during changegroup reading. This patch makes the code more complicated in order to avoid the aforementioned 3 operations. On a pre-generated mozilla-central gzip bundle, this series has the following impact on `hg unbundle` performance on my MacBook Pro: before: 358.21 real 317.69 user 38.49 sys after: 301.57 real 262.69 user 37.11 sys delta: -56.64 real -55.00 user -1.38 sys

util.chunkbuffer: refactor chunk handling logic This will make the next patch easier to read. It provides no benefit on its own.

util.chunkbuffer: special case reading everything The new code results in simpler logic within the while loop. It is also faster since we avoid performing operations on the queue and buf collections. However, there shouldn't be any super hot loops for this since the whole point of chunkbuffer is to avoid reading large amounts of data at once. This does, however, make it easier to optimize chunkbuffer in a subsequent patch.

revert: add reference to backout

backout: add reference to revert

localrepo: allow wlock to be inherited This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. When allowed, the parent process will pass down requisite information to the child process by way of this environment variable.