[PATCH STABLE v2] tags: create a supplemental cache of .hgtags filenodes (issue4550)

[Gregory Szorc]

On Tue, Mar 17, 2015 at 2:36 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Mon, 2015-03-16 at 23:08 -0700, Gregory Szorc wrote:
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1426392860 25200
> > #      Sat Mar 14 21:14:20 2015 -0700
> > # Branch stable
> > # Node ID 9e0d583a15c42f11d06b66684c9c9d85d9269d9f
> > # Parent  b73a22d1d9bfe3a7f8633340ea75a0ab1526c21b
> > tags: create a supplemental cache of .hgtags filenodes (issue4550)
>
> The _only_ thing that makes this proposal appropriate for stable is that
> it fights a performance regression.
>
> Everything else about it screams not appropriate for stable. Especially
> the part where it grows without bounds. People in the real world often
> run the same hg -for years- and if they install this on a server, they
> could have a 1-to-1 ratio of cache entries to changelog entries.
>
> But this is also the first time I've seen the ALARMING numbers related
> to this bug, which is why I haven't been paying much attention.
> Specifically, they're not in your bug report ("dozens of seconds" with
> no baseline), which you self-triaged without cc:ing any guilty parties
> and thus slipped entirely past my radar.
>
> Have you actually identified the problematic change in 3.3? Can we back
> it out?
>
> I'm still tempted to re-release 3.2.4 as 3.3.x due to the number of
> untended regressions.


I posted some numbers to the bug last night. I have not yet identified a
regression range. In fact, I /think/ the evolve extension might have
regressed (passing an unfiltered repo to something that reads tags).

I think you've talked me out of trying to land this in stable.

What do I need to change for this to land in default?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150319/08f219b1/attachment.html>