So invalidate is by design not-always invalidating and it’s relying on
filecache to actually invalidate dirstate
when needed? Why do we even need the invalidate in this case if filecache can
always properly invalidate dirstate?
Best,
Mateusz
On 8/26/16, 5:02 PM, "Yuya Nishihara" <you...@gmail.com on behalf of
y...@tcha.org> wrote:
On Fri, 26 Aug 2016 08:31:09 -0700, Mateusz Kwapich wrote:
> # HG changeset patch
> # User Mateusz Kwapich <mitran...@fb.com>
> # Date 1472225341 25200
> # Fri Aug 26 08:29:01 2016 -0700
> # Node ID 430e8c2cc229e0fbed231370c36cc2a215ecb30e
> # Parent 318e2b600b80e4ed3c6f37df46ec7544f60d4c0b
> localrepo: actually invalidate dirstate on invalidatedirstate()
>
> The old dirstate was still present in the filecache. It was invalidated
only
> because filecache did stat the file on the next access. This can lead to
errors
> in the case when file stat didn't change but the dirstate contents did
change
> (and we know about it and thats why we sometimes call
dirstateinvalidate() to
> refresh it).
(+CC foozy since he's working on fixing timestamp issues)
IIRC, that's by design. invalidate() just forces to compare timestamps to
see
if in-memory cache is valid.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
