[RFC] Interaction between strip and caches
Augie Fackler
raf at durin42.com
Sat Feb 27 03:52:52 UTC 2021
> On Dec 14, 2020, at 5:03 PM, Joerg Sonnenberger <joerg at bec.de> wrote:
>
> Hello all,
> while looking at the revbranchcache, I noticed that it is doing quite an
> expensive probalistic invalidation dance. It is essentially looking up
> the revision in the changelog again and compares the first 32bit to see
> if they (still) match. Other caches are doing cheaper checks like
> remembering the head revision and node and checking it again to match.
> The goal is in all cases to detect one of two cases:
>
> (1) Repository additions by a hg instance without support for the cache.
> (2) Repository removals by strip without update support specific to the
> cache in use.
>
> The first part is generally handled reasonable well and cheap. Keep
> track of the number of revisions and process to all missing changesets
> is something code has to support anyway. The real difficult problem is
> the second part. I would like us to adopt a more explicit way of dealing
> with this and opt-in support via a repository requirement. Given that
> the strip command has finally become part of core, it looks like a good
> time to do this now.
>
> The first option is to require strip to nuke all caches that it can't
> update. This is easy to implement and works reliable by nature with all
> existing caches. It is also the more blunt option.
Wonât the caches invalidate themselves an this defect happens today?
> The second option is to keep a journal of strips. This can be a single
> monotonically increasing counter and every cache just reads the counter
> and rebuilds itself. Alternatively it could be a full journal that lists
> the revisions and associated nodes removed. This requires changes to
> existing caches but has the advantage that strip can be replayed by the
> cache logic to avoid a full rebuild.
Potentially complicated, but could be worthwhile in a large repo with strips. Is that something you expect to encounter? For the most part weâve historically considered strip an anti-pattern of sorts and not worried super hard about optimizing it.
>
> Joerg
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
More information about the Mercurial-devel
mailing list