bundlerepo: disable filtering of changelog while constructing revision text This avoids the following error that happened if base revision of bundle file was hidden. bundlerevlog needs it to construct revision texts from bundle content as revlog.revision() does. File "mercurial/context.py", line 485, in _changeset return self._repo.changelog.read(self.rev()) File "mercurial/changelog.py", line 319, in read text = self.revision(node) File "mercurial/bundlerepo.py", line 124, in revision text = self.baserevision(iterrev) File "mercurial/bundlerepo.py", line 160, in baserevision return changelog.changelog.revision(self, nodeorrev) File "mercurial/revlog.py", line 1041, in revision node = self.node(rev) File "mercurial/changelog.py", line 211, in node raise error.FilteredIndexError(rev) mercurial.error.FilteredIndexError: 1

merge: run update hook after the last wlock release There were 2 test failures in 3.4-rc when running test-hook.t with the largefiles extension enabled. For context, the first is a commit hook: @@ -618,9 +621,9 @@ $ echo 'update = hg id' >> .hg/hgrc $ echo bb > a $ hg ci -ma - 223eafe2750c tip + d3354c4310ed+ $ hg up 0 - cb9a9f314b8b + 223eafe2750c+ tip 1 files updated, 0 files merged, 0 files removed, 0 files unresolved make sure --verbose (and --quiet/--debug etc.) are propagated to the local ui In both cases, largefiles acquires the wlock before calling into core, which also acquires the wlock. The first case was fixed in 57f1dbc99631 by ensuring the hook only runs after the lock has been fully released. The full release is important, because that is what writes dirstate to the disk, allowing external hooks to see the result of the update. This simply changes how the update hook is called, so that it too is deferred until the lock is finally released. There are many uses of mergemod.update(), but in terms of commands, it looks like the following commands take wlock while calling mergemod.update(), and therefore will now have their hook fired at a later time: backout, fetch, histedit, qpush, rebase, shelve, transplant Unlike the others, fetch immediately unlocks after calling update(), so for all intents and purposes, its hook invocation is not deferred (but the external hook still sees the proper state).

censor: remove meaningless explanation about .hgcensored There is no code path handling ".hgcensored" in Mercurial source tree. This meaningless explanation may make users misunderstand about censor.

parsers: avoid signed integer overflow in calculation of leaf-node index If v = -INT_MAX - 1, -v would exceed INT_MAX. I don't think this would cause problems such as issue4627, but we can't blame it as a compiler bug because signed integer overflow is undefined in C.

bundle2: disable ouput capture unless we use http (issue4613 issue4615) The current bundle2 processing was capturing all output. This is nice as it provide better meta data about what output what, but this was changing two things: 1) adding a prefix "remote: " to "other" output during local push (issue4613) 2) local and ssh push does not provide real time output anymore (issue4615) As we are unsure about what form should be used in (1) and how to solve (2) we disable output capture in this two cases. Output capture can be forced using an experimental option.

subrepo: propagate the --hidden option to hg subrepositories With many commands accepting a '-S' or an explicit path to trigger recursing into subrepos, it seems that --hidden needs to be propagated too. Unfortunately, many of the subrepo layer methods discard the options map, so passing the option along explicitly isn't currently an option. It also isn't clear if other filtered views need to be propagated, so changing all of those commands may be insufficient anyway. The specific jam I got into was amending an ancestor of qbase in a subrepo, and then evolving. The patch ended up being hidden, and outgoing said it would only push one unrelated commit. But push aborted with an 'unknown revision' that I traced back to the patch. (Odd it didn't say 'filtered revision'.) A push with --hidden worked from the subrepo, but that wasn't possible from the parent repo before this. Since the underlying problem doesn't actually require a subrepo, there's probably more to investigate here in the discovery area. Yes, evolve + mq is not exactly sane, but I don't know what is seeing the hidden revision. In lieu of creating a test for the above situation (evolving mq should probably be blocked), the test here is a marginally useful case where --hidden is needed in a subrepo: cat'ing a file in a hidden revision. Without this change, cat aborts with: $ hg --hidden cat subrepo/a skipping missing subrepository: subrepo [1]

subrepo: don't pass the outer repo's --rev or --branch to subrepo incoming() When passing a --rev, 'hg incoming -S' previously suffered from the same output truncation or abort that was fixed for 'hg outgoing -S' in the previous patch, for the same reasons. Unlike push, subrepos are currently only pulled when the outer repo is updated, not when the outer repo is pulled. That makes matching 'hg pull' behavior impossible. Listing all incoming csets in the subrepo seems like the most useful behavior, and is consistent with 'hg outgoing -S'.

subrepo: don't pass the outer repo's --rev or --branch to subrepo outgoing() The previous behavior didn't reflect what would actually be pushed- push will ignore --rev and --branch in the subrepo and push everything. Therefore, 'push -r {rev}' would not list everything, unless {rev} was also the revision of the subrepo's tip. Worse, if a hash was passed in, the command would abort because that hash would either not be in the outer repo or not in the subrepo.

subrepo: update the help text to account for diff -I/-X gitsubrepo support The functionality was added in a48b65ab428d.

revert: make the interactive mode experimental While fixing issue4304: "record: allow editing new files" we introduced changes in record/crecord. These changes need to be matched with changes in any command using record. Revert is one of these commands and the changes have not been made for this release. Therefore, revert -i should be an experimental feature for this release.