pull: print "pulling from foo" before accessing the other repo 1. This is consistent with pushing. 2. This allows to see the URL of the other repo in case accessing the repo fails, e.g. wrong ssh path or issues with the https certificate, without using --debug or showconfig paths. Additionally add test for this in the context of ssh with a wrong path.

error.LookupError: rename 'message' property to something else At least some installs of Python 2.6+ complain with: mercurial/error.py:26: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 This patch renames the property away from 'message' so that Python no longer complains.

hgweb: use introrev() for finding parents (issue4506) The issue is titled "filtered revision 'XXX' (not in 'served' subset)" and that is the error message you sometimes get when trying to look at a file (/file or /annotate) in hgweb. For example: http://hg.intevation.org/mercurial/crew/file/90cf454edd70/mercurial/cmdutil.py This happens when a parent revision for a file is hidden, thus it is not 'served' and isn't accessible in hgweb by default. When hgweb tries to access such changeset, it produces the error and HTTP status code 404. Another detail is that the parents() function, that is used in multiple places in hgweb, sometimes returned changesets that were obsoleted by the current changeset for the file. For example, when using rebase with evolve and rebasing a divergent changeset that introduces a file on top of current branch. Or grafting a change and making the new grafted changeset obsolete the source (shown in the test case). The result is the same - the obsoleted changeset was mistakingly returned from parents(), even though it's not a parent and the only link to the new changeset is an obsoletion marker (and rebase/graft metadata? not sure it matters). The problem is fixed by using introrev() instead of linkrev() for finding parents. This prevents parents() function from returning unrelated obsolete changesets. The test case prepares a separate repo because (afaict) all other test cases never reuse file names, so there are no files that were changed in multiple changesets. So no previously available files have obsolete changesets in their history.

subrepo: drop unused pattern initialization in hgsubrepo revert This passed an empty list to filerevert() if '--all' was specified, otherwise the set of modified files. But then filerevert() immediately switched this and reinitialized 'pats' to an empty list if '--all' was *not* specified.

revert: display full subrepo output with --dry-run Since the point of --dry-run is to show what will happen, the output with and without it should agree. And since revert wasn't being called on subrepos with --dry-run before, revert in the subrepo had to be defanged in this case.

largefiles: don't warn when reverting a forgotten largefile Previously, when a largefile is forgotten and then reverted, a warning was issued: $ hg revert -R subrepo subrepo/large.txt file not managed: subrepo/large.txt (glob) This was purely cosmetic as the file itself actually was reverted. The problem was even with all of the matcher patching, the largefile pattern given on the command line wasn't converted to a standin because the standin was neither in ctx nor wctx. This causes the named largefile to be added to the 'names' dict in cmdutil.revert() in the repo walk at line 2550. The warning was printed out when the 'names' dict is iterated, because the file was specified exactly. Since core revert recurses into subrepos and largefiles only overrides the revert method in commands.py, it doesn't work properly when reverting a subrepo. However, it still will recurse into the subrepo and call the installed matcher method, so lfdirstate is reopened for the current repo level to prevent any new problems.

subrepo: annotate addremove with @annotatesubrepoerror

histedit: don't recreate state object Previously, the histedit state object was being recreated during continue/abort. This meant that the locks that were held on the original state object were not available to actions, which meant actions could not release the lock on the repository (like an 'exec' action would need to do). This affected our internal extension that added the 'exec' action.