Added signature for changeset 5b4ed033390b

Added tag 3.3.1 for changeset 5b4ed033390b

revisionbranchcache: fall back to slow path if starting readonly (issue4531) Transitioning to Mercurial versions with revision branch cache could be slow as long as all operations were readonly (revset queries) and the cache would be populated but not written back. Instead, fall back to using the consistently slow path when readonly and the cache doesn't exist yet. That avoids the overhead of populating the cache without writing it back. If not readonly, it will still populate all missing entries initially. That avoids repeated writing of the cache file with small updates, and it also makes sure a fully populated cache available for the readonly operations.

largefiles: access to specific fields only if largefiles enabled (issue4547) Even if largefiles extension is enabled in a repository, "repo" object, which isn't "largefiles.reposetup()"-ed, is passed to overridden functions in the cases below unexpectedly, because extensions are enabled for each repositories strictly. (1) clone without -U: (2) pull with -U: (3) pull with --rebase: combination of "enabled@src", "disabled@dst" and "not-required@src" cause this situation. largefiles requirement @src @dst @src result -------- -------- --------------- -------------------- enabled disabled not-required aborted unexpectedly required requirement error (intentional) -------- -------- --------------- -------------------- enabled enabled * success -------- -------- --------------- -------------------- disabled enabled * success (only for "pull") -------- -------- --------------- -------------------- disabled disabled not-required success required requirement error (intentional) -------- -------- --------------- -------------------- (4) update/revert with a subrepo disabling largefiles In these cases, overridden functions cause accessing to largefiles specific fields of not "largefiles.reposetup()"-ed "repo" object, and execution is aborted. - (1), (2), (4) cause accessing to "_lfstatuswriters" in "getstatuswriter()" invoked via "updatelfiles()" - (3) causes accessing to "_lfcommithooks" in "overriderebase()" For safe accessing to these fields, this patch examines whether passed "repo" object is "largefiles.reposetup()"-ed or not before accessing to them. This patch chooses examining existence of newly introduced "_largefilesenabled" instead of "_lfcommithooks" and "_lfstatuswriters" directly, because the former is better name for the generic "largefiles is enabled in this repo" mark than the latter. In the future, all other overridden functions should avoid largefiles specific processing for efficiency, and "_largefilesenabled" is better also for such purpose. BTW, "lfstatus" can't be used for such purpose, because some code paths set it forcibly regardless of existence of it in specified "repo" object.

templatekw: fix {join(bookmarks, sep)} to always show associated bookmarks The default joinfmt, "x.values()[0]", can't be used here because it picks either 'bookmark' or 'current' randomly. I got wrong result with PYTHONHASHSEED=1 on my amd64 machine.

templatekw: inline showlist() into showbookmarks() showlist() is the helper to build _hybrid object from a trivial list. It can't be applied if each value has more than one items, 'bookmark' and 'current' in this case. This change is necessary to fix random failure of "{join(bookmarks, sep)}".

transaction: disable hardlink backups (issue4546) Causing troubles, simplest fix.

repoview: invalidate cached changelog if _delayed changes (issue4549) Starting with 2d54aa5397cd, when a clone reached the checkout stage, the cached changelog in the filtered view was still seeing the _delayed flag, even though the changelog had already been finalized.

test: make test-extdiff resilient to */gnubin/echo My Mac test machine has 'echo' in '/opt/local/libexec/gnubin/echo' since, well, GNU is not BSD. Also, I feel it need to be said about using regexes: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

dispatch: work around UnicodeDecodeError caused by SSLError of Python 2.7.9 SSLError of Python 2.7.9 may keep error message in unicode. It will be wrapped by URLError(reason) at KeepAliveHandler.do_open, so inst.reason can be a unicode. https://hg.python.org/cpython/file/v2.7.9/Modules/_ssl.c#l329

revset: mask specific names for named() predicate Before this patch, revset predicate "tag()" and "named('tags')" differ from each other, because the former doesn't include "tip" but the latter does. For equivalence, "named('tags')" shouldn't include the revision corresponded to "tip". But just removing "tip" from the "tags" namespace causes breaking backward compatibility, even though "tip" itself is planned to be eliminated, as mentioned below. http://selenic.com/pipermail/mercurial-devel/2015-February/066157.html To mask specific names ("tip" in this case) for "named()" predicate, this patch introduces "deprecated" into "namespaces", and makes "named()" predicate examine whether each names are masked by the namespace, to which they belong. "named()" will really work correctly after 3.3.1 (see 873eb5db89c8 for detail), and fixing this on STABLE before 3.3.1 can prevent initial users of "named()" from expecting "named('tags')" to include "tip". It is reason why this patch is posted for STABLE, even though problem itself isn't so serious. This may have to be flagged as "(BC)", if applied on DEFAULT.

i18n-pt_BR: synchronized with 756c5c8331b0

i18n-ja: synchronized with 756c5c8331b0

merge with stable

manifest: rename 'mf', 'map', and 'mapping' to 'm' We mostly call manifest variables 'm', so let's use that in manifest.py too. This makes it clearer that the variables do, in fact, contain manifestsdict instances and never a plain dict.

manifest: make copy logic local to copy() The optional arguments to the manfifestdict constructor are only used by copy(), so assign the fields from that method instead so it's clear that the arguments are not used for anything else.

extensions: indicate loaded for an immediately called afterload callback Otherwise, there's no way to tell between the immediate callback when it is already loaded, and when the extension is not loaded at all.

tests: add test showing tags cache drops filtered heads (issue4550) The tags cache can lose .hgtags filenode entries for filtered heads. Add a test demonstrating this (bad) behavior.

tags: write tags cache deterministically An upcoming test verifies content of the .hg/cache/tags file. During testing, inconsistent output was observed. This is the result of iterating over a dictionary. Throw a sorted() around tags entries to ensure .hg/cache/tags is written deterministically so test output is stable.

histedit: add --edit-plan option to histedit --edit-plan allows user to edit remaining histedit rules in the middle of histedit process

histedit: generalize makedesc Allow makedesc to generate description for any action - not only pick. (to be used in histedit --edit-plan)

histedit: extract method ruleeditor Extract functionality of editing histedit rules to separate method so we can reuse it in upcoming --edit-plan option.

churn: deprecate -t option in favour of -T We use -T consistently elsewhere to refer to the --template option. The old -t option is now renamed to --oldtemplate so that -t still works. This has the benign side effect of introducing and immediately deprecating a new long option. We also test with both -t and -T options.

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.