Mercurial > hg
view tests/test-journal-share.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 | 0103b673d6ca |
children | 9843e3d9f4b6 |
line wrap: on
line source
Journal extension test: tests the share extension support $ cat >> testmocks.py << EOF > # mock out util.getuser() and util.makedate() to supply testable values > import os > from mercurial import util > def mockgetuser(): > return 'foobar' > > def mockmakedate(): > filename = os.path.join(os.environ['TESTTMP'], 'testtime') > try: > with open(filename, 'rb') as timef: > time = float(timef.read()) + 1 > except IOError: > time = 0.0 > with open(filename, 'wb') as timef: > timef.write(str(time)) > return (time, 0) > > util.getuser = mockgetuser > util.makedate = mockmakedate > EOF $ cat >> $HGRCPATH << EOF > [extensions] > journal= > share= > testmocks=`pwd`/testmocks.py > [remotenames] > rename.default=remote > EOF $ hg init repo $ cd repo $ hg bookmark bm $ touch file0 $ hg commit -Am 'file0 added' adding file0 $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . commit -Am 'file0 added' 5640b525682e bm commit -Am 'file0 added' A shared working copy initially receives the same bookmarks and working copy $ cd .. $ hg share repo shared1 updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd shared1 $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . share repo shared1 unless you explicitly share bookmarks $ cd .. $ hg share --bookmarks repo shared2 updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd shared2 $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . share --bookmarks repo shared2 5640b525682e bm commit -Am 'file0 added' Moving the bookmark in the original repository is only shown in the repository that shares bookmarks $ cd ../repo $ touch file1 $ hg commit -Am "file1 added" adding file1 $ cd ../shared1 $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . share repo shared1 $ cd ../shared2 $ hg journal --all previous locations of the working copy and bookmarks: 6432d239ac5d bm commit -Am 'file1 added' 5640b525682e . share --bookmarks repo shared2 5640b525682e bm commit -Am 'file0 added' But working copy changes are always 'local' $ cd ../repo $ hg up 0 0 files updated, 0 files merged, 1 files removed, 0 files unresolved (leaving bookmark bm) $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . up 0 6432d239ac5d . commit -Am 'file1 added' 6432d239ac5d bm commit -Am 'file1 added' 5640b525682e . commit -Am 'file0 added' 5640b525682e bm commit -Am 'file0 added' $ cd ../shared2 $ hg journal --all previous locations of the working copy and bookmarks: 6432d239ac5d bm commit -Am 'file1 added' 5640b525682e . share --bookmarks repo shared2 5640b525682e bm commit -Am 'file0 added' $ hg up tip 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg up 0 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg journal previous locations of '.': 5640b525682e up 0 6432d239ac5d up tip 5640b525682e share --bookmarks repo shared2 Unsharing works as expected; the journal remains consistent $ cd ../shared1 $ hg unshare $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . share repo shared1 $ cd ../shared2 $ hg unshare $ hg journal --all previous locations of the working copy and bookmarks: 5640b525682e . up 0 6432d239ac5d . up tip 6432d239ac5d bm commit -Am 'file1 added' 5640b525682e . share --bookmarks repo shared2 5640b525682e bm commit -Am 'file0 added' New journal entries in the source repo no longer show up in the other working copies $ cd ../repo $ hg bookmark newbm -r tip $ hg journal newbm previous locations of 'newbm': 6432d239ac5d bookmark newbm -r tip $ cd ../shared2 $ hg journal newbm previous locations of 'newbm': no recorded locations This applies for both directions $ hg bookmark shared2bm -r tip $ hg journal shared2bm previous locations of 'shared2bm': 6432d239ac5d bookmark shared2bm -r tip $ cd ../repo $ hg journal shared2bm previous locations of 'shared2bm': no recorded locations