Mercurial > hg
view tests/test-dirstate.t @ 29917:f32f8bf5dc4c
streamclone: force @filecache properties to be reloaded from file
Before this patch, consumev1() invokes repo.invalidate() after closing
transaction, to force @filecache properties to be reloaded from files
at next access, because streamclone writes data into files directly.
But this doesn't work as expected in the case below:
1. at closing transaction, repo._refreshfilecachestats() refreshes
file stat of each @filecache properties with streamclone-ed files
This means that in-memory properties are treated as valid.
2. but streamclone doesn't changes in-memory properties
This means that in-memory properties are actually invalid.
3. repo.invalidate() just forces to examine file stat of @filecache
properties at the first access after it
Such examination should concludes that reloading from file isn't
needed, because file stat was already refreshed at (1).
Therefore, invalid in-memory cached properties (2) are
unintentionally treated as valid (1).
This patch invokes repo.invalidate() with clearfilecache=True, to
force @filecache properties to be reloaded from file at next access.
BTW, it is accidental that repo.invalidate() without
clearfilecache=True in streamclone case seems to work as expected
before this patch.
If transaction is started via "filtered repo" object,
repo._refreshfilecachestats() tries to refresh file stat of each
@filecache properties on "filtered repo" object, even though all of
them are stored into "unfiltered repo" object.
In this case, repo._refreshfilecachestats() does nothing
unintentionally, but this unexpected behavior causes reloading
@filecache properties after repo.invalidate().
This is reason why this patch should be applied before making
_refreshfilecachestats() correctly refresh file stat of @filecache
properties.
author | FUJIWARA Katsunori <foozy@lares.dti.ne.jp> |
---|---|
date | Mon, 12 Sep 2016 03:06:28 +0900 |
parents | 56b2bcea2529 |
children | b9765319880e |
line wrap: on
line source
------ Test dirstate._dirs refcounting $ hg init t $ cd t $ mkdir -p a/b/c/d $ touch a/b/c/d/x $ touch a/b/c/d/y $ touch a/b/c/d/z $ hg ci -Am m adding a/b/c/d/x adding a/b/c/d/y adding a/b/c/d/z $ hg mv a z moving a/b/c/d/x to z/b/c/d/x (glob) moving a/b/c/d/y to z/b/c/d/y (glob) moving a/b/c/d/z to z/b/c/d/z (glob) Test name collisions $ rm z/b/c/d/x $ mkdir z/b/c/d/x $ touch z/b/c/d/x/y $ hg add z/b/c/d/x/y abort: file 'z/b/c/d/x' in dirstate clashes with 'z/b/c/d/x/y' [255] $ rm -rf z/b/c/d $ touch z/b/c/d $ hg add z/b/c/d abort: directory 'z/b/c/d' already in dirstate [255] $ cd .. Issue1790: dirstate entry locked into unset if file mtime is set into the future Prepare test repo: $ hg init u $ cd u $ echo a > a $ hg add adding a $ hg ci -m1 Set mtime of a into the future: $ touch -t 202101011200 a Status must not set a's entry to unset (issue1790): $ hg status $ hg debugstate n 644 2 2021-01-01 12:00:00 a Test modulo storage/comparison of absurd dates: #if no-aix $ touch -t 195001011200 a $ hg st $ hg debugstate n 644 2 2018-01-19 15:14:08 a #endif Verify that exceptions during a dirstate change leave the dirstate coherent (issue4353) $ cat > ../dirstateexception.py <<EOF > from mercurial import merge, extensions, error > > def wraprecordupdates(orig, repo, actions, branchmerge): > raise error.Abort("simulated error while recording dirstateupdates") > > def reposetup(ui, repo): > extensions.wrapfunction(merge, 'recordupdates', wraprecordupdates) > EOF $ hg rm a $ hg commit -m 'rm a' $ echo "[extensions]" >> .hg/hgrc $ echo "dirstateex=../dirstateexception.py" >> .hg/hgrc $ hg up 0 abort: simulated error while recording dirstateupdates [255] $ hg log -r . -T '{rev}\n' 1 $ hg status ? a