D6710: branchmap: explicitly warm+write all subsets of the branchmap caches

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Aug 6 06:01:55 EDT 2019

Forcing this write seems like a good idea. Having it in its own 
changeset seems like a good idea (and please add a comment about forcing 
the write).

On 8/6/19 3:12 AM, spectral (Kyle Lippincott) wrote:
> spectral added inline comments.
>> marmoute wrote in localrepo.py:2224
>> Why the explicite write here ? We don't seems to need it for the previous section. Is this because if the cache of the previous subset is valid, the write would be skipped ?
>> If so, consider clarifying it in your comment.
> Actually it's because the documentation for the function states that it will "warm the caches", "even the ones usually loaded more lazily".
> If nothing in hg actually explicitly requests the subset, it won't be written:
>    $ hg init; echo hi > foo; hg ci -qAm foo; ls .hg/cache
>    branch2-served  evoext-obscache-00  rbc-names-v1  rbc-revs-v1
> This would have, I'd thought, written out -served, -immutable, and -base, since -immutable and -base are subsets of -served, but that doesn't seem to happen.  Even if I run `hg debugupdatecache` (before this change) they don't get written:
>    branch2-served  evoext-obscache-00  hgtagsfnodes1  rbc-names-v1  rbc-revs-v1  tags2  tags2-served
> If the intent of `hg debugupdatecache` is to actually warm all levels of cache, it should probably warm -immutable and -base, so that they're kept up to date? Or is that undesirable for some reason (maybe it causes additional computation every time the cache for -served is updated if -immutable and -base exist, since they'd also possibly have to be updated? I'd think it'd be the opposite (-base is very cheap to calculate, and unlikely to go stale, can be used to make calculating immutable quicker, and that can be used to make calculating served quicker.. without them, then served has to start from scratch each time; this seems to be the *reason* for the subsettable :)), but I'm not super familiar with the caching code (and uses of it) to know if this is actually true in practice.
> That said, I agree that these are two separate concerns, and the number of tests that need to be changed is pretty significant for this one, so I've split this change into two.
>    rHG Mercurial
>    https://phab.mercurial-scm.org/D6710/new/
>    https://phab.mercurial-scm.org/D6710
> To: spectral, #hg-reviewers
> Cc: marmoute, mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Pierre-Yves David

More information about the Mercurial-devel mailing list