Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 18:47:04 -0600] rev 23987
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 08:24:08 +0900] rev 23986
i18n-ja: synchronized with 9a391d720cf9
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 29 Jan 2015 10:13:18 -0200] rev 23985
i18n-pt_BR: synchronized with 448bb32b8ee6
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:33:45 -0600] rev 23984
filectx: use _descendantrev in parents()
This lets us be lazy about linkrev adjustments when tracing history.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:26:35 -0600] rev 23983
filectx: if we have a _descendantrev, use it to adjust linkrev
This lets us use _adjustlinkrev lazily.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:25:12 -0600] rev 23982
copies: use linkrev for file tracing limit
This lets us lazily evaluate _adjustlinkrev.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:23:07 -0600] rev 23981
filectx: use linkrev to sort ancestors
We're going to make rev() lazily do _adjustlinkrevs, and we don't want
that to happen when we're quickly tracing through file ancestry
without caring about revs (as we do when finding copies).
This takes us back to pre-linkrev-correction behavior, but shouldn't
regress us relative to the last stable release.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 16:02:28 +0000] rev 23980
_adjustlinkrev: reuse ancestors set during rename detection (issue4514)
The new linkrev adjustement mechanism makes rename detection very slow, because
each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we
introduce a simplistic way to share the ancestors computation for the linkrev
validation phase.
We can reuse the ancestors in that case because we do not care about
sub-branching in the ancestors graph.
The cached set will be use to check if the linkrev is valid in the search
context. This is the vast majority of the ancestors usage during copies search
since the uncached one will only be used when linkrev is invalid, which is
hopefully rare.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 14:39:03 +0000] rev 23979
filectx: move _adjustlinkrev to a method
We are going to introduce some wider caching mechanisms during linkrev
adjustment. As there is no specific reason to not be a method and some
reasons to be a method, let's make it a method.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 31 Jan 2015 01:00:50 +0900] rev 23978
revset: raise RepoLookupError to make present() predicate continue the query
Before this patch, "bookmark()", "named()" and "tag()" predicates
raise "Abort", when the specified pattern doesn't match against
existing ones.
This prevents "present()" predicate from continuing the query, because
it only catches "RepoLookupError".
This patch raises "RepoLookupError" instead of "Abort", to make
"present()" predicate continue the query, even if "bookmark()",
"named()" or "tag()" in the sub-query of it are aborted.
This patch doesn't contain raising "RepoLookupError" for "re:" pattern
in "tag()", because "tag()" treats it differently from others. Actions
of each predicates at failure of pattern matching can be summarized as
below:
predicate "literal:" "re:"
---------- ----------- ------------
bookmark abort abort
named abort abort
tag abort continue (*1)
branch abort continue (*2)
---------- ----------- ------------
"tag()" may have to abort in the (*1) case for similarity, but this
change may break backward compatibility of existing revset queries. It
seems to have to be changed on "default" branch (with "BC" ?).
On the other hand, (*2) seems to be reasonable, even though it breaks
similarity, because "branch()" in this case doesn't check exact
existence of branches, but does pick up revisions of which branch
matches against the pattern.
This patch also adds tests for "branch()" to clarify behavior around
"present()" of similar predicates, even though this patch doesn't
change "branch()".