Sun, 01 Feb 2015 18:47:04 -0600 merge with i18n stable 3.3
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 18:47:04 -0600] rev 23987
merge with i18n
Sun, 01 Feb 2015 08:24:08 +0900 i18n-ja: synchronized with 9a391d720cf9 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 08:24:08 +0900] rev 23986
i18n-ja: synchronized with 9a391d720cf9
Thu, 29 Jan 2015 10:13:18 -0200 i18n-pt_BR: synchronized with 448bb32b8ee6 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 29 Jan 2015 10:13:18 -0200] rev 23985
i18n-pt_BR: synchronized with 448bb32b8ee6
Sun, 01 Feb 2015 16:33:45 -0600 filectx: use _descendantrev in parents() stable
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.
Sun, 01 Feb 2015 16:26:35 -0600 filectx: if we have a _descendantrev, use it to adjust linkrev stable
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.
Sun, 01 Feb 2015 16:25:12 -0600 copies: use linkrev for file tracing limit stable
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.
Sun, 01 Feb 2015 16:23:07 -0600 filectx: use linkrev to sort ancestors stable
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.
Fri, 30 Jan 2015 16:02:28 +0000 _adjustlinkrev: reuse ancestors set during rename detection (issue4514) stable
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.
Fri, 30 Jan 2015 14:39:03 +0000 filectx: move _adjustlinkrev to a method stable
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.
Sat, 31 Jan 2015 01:00:50 +0900 revset: raise RepoLookupError to make present() predicate continue the query stable
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()".
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip