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

Matt Mackall mpm at selenic.com
Tue Mar 17 16:36:07 CDT 2015


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list