[PATCH 3 of 4] streamclone: clear caches after writing changes into files for visibility

Yuya Nishihara yuya at tcha.org
Tue Sep 6 10:13:37 EDT 2016


On Sat, 03 Sep 2016 03:34:12 +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1472840249 -32400
> #      Sat Sep 03 03:17:29 2016 +0900
> # Node ID 33e29b5ebe885cdeeef433861e2d165b882d48d1
> # Parent  32f53aaf63f8db0c1352a3b0afb290c425486704
> streamclone: clear caches after writing changes into files for visibility
> 
> Before this patch, streamclone-ed changes are invisible via @filecache
> properties to in-process procedures before closing transaction
> (e.g. pretxnclose python hook), if corresponded property is cached
> before consumev1(). Strictly speaking, caching should occur inside
> (store) lock for transaction.
> 
> repo.invalidate() after closing transaction is too late to force
> @filecache properties to be reloaded from changed files at next
> access.
> 
> For visibility of streamclone-ed changes to in-process procedures
> before closing transaction, this patch clears caches just after
> writing changes into files.
> 
> Simply moving repo.invalidate() invocation into transaction scope
> causes unexpected result, because it clears in-memory changes of
> fncache before writing them out at closing transaction. "unexpected
> result" requires rebuilding fncache by "hg debugrebuildfncache".

Does it mean store.invalidatecaches() should always be omitted in transaction?
If that's true, I'd rather make repo.invalidate() skip it conditionally
and add a comment why.

> -        # Writing straight to files circumvented the inmemory caches
> -        repo.invalidate(clearfilecache=True)
> +            # force @filecache properties to be reloaded from
> +            # streamclone-ed file at next access
> +            repo.invalidatefilecaches(clearcache=True)
> +
> +            # clear already cached @propertycache properties or so
> +            repo.invalidatecaches()

It seems obscure that we should never call store.invalidatecaches() here.
I think that is the matter of the localrepo.


More information about the Mercurial-devel mailing list