Mercurial > hg
view tests/test-patch-offset.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 | a387b0390082 |
children | 75be14993fda |
line wrap: on
line source
$ cat > writepatterns.py <<EOF > import sys > > path = sys.argv[1] > patterns = sys.argv[2:] > > fp = file(path, 'wb') > for pattern in patterns: > count = int(pattern[0:-1]) > char = pattern[-1] + '\n' > fp.write(char*count) > fp.close() > EOF prepare repo $ hg init a $ cd a These initial lines of Xs were not in the original file used to generate the patch. So all the patch hunks need to be applied to a constant offset within this file. If the offset isn't tracked then the hunks can be applied to the wrong lines of this file. $ python ../writepatterns.py a 34X 10A 1B 10A 1C 10A 1B 10A 1D 10A 1B 10A 1E 10A 1B 10A $ hg commit -Am adda adding a This is a cleaner patch generated via diff In this case it reproduces the problem when the output of hg export does not import patch $ hg import -v -m 'b' -d '2 0' - <<EOF > --- a/a 2009-12-08 19:26:17.000000000 -0800 > +++ b/a 2009-12-08 19:26:17.000000000 -0800 > @@ -9,7 +9,7 @@ > A > A > B > -A > +a > A > A > A > @@ -53,7 +53,7 @@ > A > A > B > -A > +a > A > A > A > @@ -75,7 +75,7 @@ > A > A > B > -A > +a > A > A > A > EOF applying patch from stdin patching file a Hunk #1 succeeded at 43 (offset 34 lines). Hunk #2 succeeded at 87 (offset 34 lines). Hunk #3 succeeded at 109 (offset 34 lines). committing files: a committing manifest committing changelog created 189885cecb41 compare imported changes against reference file $ python ../writepatterns.py aref 34X 10A 1B 1a 9A 1C 10A 1B 10A 1D 10A 1B 1a 9A 1E 10A 1B 1a 9A $ diff aref a $ cd ..