At Tue, 6 Sep 2016 23:13:37 +0900, Yuya Nishihara wrote: > > On Sat, 03 Sep 2016 03:34:12 +0900, FUJIWARA Katsunori wrote: > > # HG changeset patch > > # User FUJIWARA Katsunori <fo...@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.
You are right. I'll send revised series. > > - # 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. > ---------------------------------------------------------------------- [FUJIWARA Katsunori] fo...@lares.dti.ne.jp _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel