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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip