Mercurial > hg
view tests/test-glog-topological.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 | 2188f170f5b6 |
children | 46825334f270 |
line wrap: on
line source
This test file aims at test topological iteration and the various configuration it can has. $ cat >> $HGRCPATH << EOF > [ui] > logtemplate={rev}\n > EOF On this simple example, all topological branch are displayed in turn until we can finally display 0. this implies skipping from 8 to 3 and coming back to 7 later. $ hg init test01 $ cd test01 $ hg unbundle $TESTDIR/bundles/remote.hg adding changesets adding manifests adding file changes added 9 changesets with 7 changes to 4 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) $ hg log -G o 8 | | o 7 | | | o 6 | | | o 5 | | | o 4 | | o | 3 | | o | 2 | | o | 1 |/ o 0 (display all nodes) $ hg log -G -r 'sort(all(), topo)' o 8 | o 3 | o 2 | o 1 | | o 7 | | | o 6 | | | o 5 | | | o 4 |/ o 0 (revset skipping nodes) $ hg log -G --rev 'sort(not (2+6), topo)' o 8 | o 3 : o 1 | | o 7 | : | o 5 | | | o 4 |/ o 0 (begin) from the other branch $ hg log -G -r 'sort(all(), topo, topo.firstbranch=5)' o 7 | o 6 | o 5 | o 4 | | o 8 | | | o 3 | | | o 2 | | | o 1 |/ o 0