hidden: remove _consistencyblockers() Roughly speaking, we currently do this to reveal hidden ancestors of visible revisions: 1. Iterate over all visible non-public revisions and see if they have hidden parents 2. For each revision found in step (1) walk the chain of hidden commits and reveal it We can simplify that by skipping step (1) and doing step (2) from all visible non-public revisions instead. This doesn't seem to have much impact on "perfvolatilesets". Before: ! obsolete ! wall 0.004616 comb 0.000000 user 0.000000 sys 0.000000 (best of 570) ! visible ! wall 0.008235 comb 0.010000 user 0.010000 sys 0.000000 (best of 326) After: ! obsolete ! wall 0.004727 comb 0.010000 user 0.010000 sys 0.000000 (best of 543) ! visible ! wall 0.008371 comb 0.000000 user 0.000000 sys 0.000000 (best of 324)

hidden: pass revs to iterate into _consistencyblockers() Instead of passing the domain into _consistencyblockers() and having the function calculate the set of revisions to iterate over, let the caller do it. This is just a minor refactoring to make future changes simpler.

hidden: remove unnecessary 'domain' parameter from _revealancestors() The function will stop searching as soon as it runs into a non-hidden revision, so there is no need to restrict by the domain (of mutable revisions) as well. This doesn't seem to have much impact on "perfvolatilesets". Before: ! obsolete ! wall 0.004903 comb 0.000000 user 0.000000 sys 0.000000 (best of 535) ! visible ! wall 0.008913 comb 0.010000 user 0.010000 sys 0.000000 (best of 300) After: ! obsolete ! wall 0.004616 comb 0.000000 user 0.000000 sys 0.000000 (best of 570) ! visible ! wall 0.008235 comb 0.010000 user 0.010000 sys 0.000000 (best of 326)

hidden: change _domainancestors() to _revealancestors() This change makes the function actually reveal the ancestors by removing them from the hidden set. This prepares for further simplification. Note that the function will now only reveal contiguous chains of hidden revisions, but that's fine because we always pass it an immediate child of any revision that should be revealed (or the revision itself). This doesn't seem to have much impact on "perfvolatilesets". Before: ! obsolete ! wall 0.004672 comb 0.010000 user 0.010000 sys 0.000000 (best of 590) ! visible ! wall 0.008936 comb 0.010000 user 0.010000 sys 0.000000 (best of 322) After: ! obsolete ! wall 0.004903 comb 0.000000 user 0.000000 sys 0.000000 (best of 535) ! visible ! wall 0.008913 comb 0.010000 user 0.010000 sys 0.000000 (best of 300)

hidden: rename "revealedrevs" to "pinnedrevs" (API) E.g. tags and bookmarks can reveal revisions that would otherwise be hidden. A revision can also be revealed because one if its descendants is visible. Let's use the term "pinned" for the former case (bookmarks etc.).

hidden: drop obsolete comment about cacheability The cache was recently dropped, so I believe the comment is now obsolete.

cat: add formatter support This is an example showing how formatter can handle the --output option. git subrepo isn't supported for now.

cat: use with statement to close output file

cat: stop using makefileobj() Prepares for porting to the formatter API. We won't be able to utilize the abstraction provided by makefilename() because formatter must be instantiated per file.

formatter: add nullformatter This can be used as a placeholder variable.

formatter: add helper to create a formatter optionally backed by file To make things simple, openformatter() and maybereopen() have no support for a plain object API. Callers must use the "with" statement. Unlike cmdutil.makefileobj(), append mode ('ab') isn't supported by these functions. This is because JSON output can't be simply concatenated. Perhaps cmdutil.export() will have to build a {filename: [revs...]} map first and write revs per file.

formatter: add option to redirect output to file object Commands like 'export' have --output=OUTFILESPEC option, so we need a way to write formatter output optionally to a file.

merge with i18n

i18n-pt_BR: synchronized with a0e46f6b248b

zsh_completion: install as _hg not hg The contrib/zsh_completion file itself says to name it _hg. With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)` in their zshrc, it will create a shell function named `hg` that will hide the actual hg command and make hg unusable. Separately from that though, the underscore prefix makes it actually work. The zsh man page states: The convention for autoloaded functions used in completion is that they start with an underscore This does not seem to just be a "convention", though. With the ill-advised line removed from my zshrc and the file named `/usr/local/share/zsh/site-functions/hg` (without the underscore), these completions did not seem to get loaded and the ones from the zsh installation were loaded instead. If I renamed them to be `/usr/local/share/zsh/site-functions/_hg`, however, they were loaded. I manually tested the above statement by starting a new zsh instance with the file in `/usr/local/share/zsh/site-functions` with the following names: - As `hg`, `which _hg_labels` did not show anything - As `_hg`, `which _hg_labels` showed the expected function.

osx: override default exclude filter for pkgbuild To quote `man 1 pkgbuild`: --filter filter-expression By default, --root will include the entire contents of the given root-path in the package payload, except for any .svn or CVS directories, and any .DS_Store files. You can override these default filters by specifying one or more --filter options. Each filter-expression is an re_format(7) ``extended'' expression: any path in the root which matches any of the given expressions will be excluded from the pack- age payload. (Note that specifying even one --filter inhibits the default filters, so you must respecify the default fil- ters if you still want them to be used.) It turns out the default filter these days *also* includes .git and .hg. Notice how that filter expression is a regular expression? That (presumably unintentionally) prevents a file named "chg" or "_hg" from getting included in the distribution. Many many thanks to spectral@ for trying to include a _hg file which led us to figure this bug out. Bug filed with Apple for this as rdar://problem/32437369, mentioning both the gap in documentation and the wrong defaults.