repoview: discard filtered changelog if index isn't shared with unfiltered
Before this patch, revisions rollbacked at failure of previous
transaction might be visible at subsequent operations unintentionally,
if repoview object is reused even after failure of transaction:
e.g. command server and HTTP server are typical cases.
'repoview' uses the tuple of values below of unfiltered changelog as
"the key" to examine validity of filtered changelog cache.
- length
- tip node
- filtered revisions (as hashed value)
- '_delayed' field
'repoview' compares between "the key" of unfiltered changelog at
previous caching and now, and reuses filtered changelog cache if no
change is detected.
But this comparison indicates only that there is no change between
unfiltered 'repo.changelog' at last caching and now, but not that
filtered changelog cache is valid for current unfiltered one.
'repoview' uses "shallow copy" of unfiltered changelog to create
filtered changelog cache. In this case, 'index' buffer of unfiltered
changelog is also referred by filtered changelog.
At failure of transaction, unfiltered changelog itself is invalidated
(= un-referred) on the 'repo' side (see
0a7610758c42 also). But
'index' of it still contains revisions to be rollbacked at this
failure, and is referred by filtered changelog.
Therefore, even if there is no change between unfiltered
'repo.changelog' at last caching and now, steps below makes rollbacked
revisions visible via filtered changelog unintentionally.
1. instantiate unfiltered changelog as 'repo.changelog'
(call it CL1)
2. make filtered (= shallow copy of) CL1
(call it FCL1)
3. cache FCL1 with "the key" of CL1
4. revisions are appended to 'index', which is shared by CL1 and FCL1
5. invalidate 'repo.changelog' (= CL1) at failure of transaction
6. instantiate 'repo.changelog' again at next operation
(call it CL2)
CL2 doesn't have revisions added at (4), because it is
instantiated from '00changelog.i', which isn't changed while
failed transaction.
7. compare between "the key" of CL1 and CL2
8. FCL1 cached at (3) is reused, because comparison at (7) doesn't
detect change between CL1 at (1) and CL2
9. revisions rollbacked at (5) are visible via FCL1 unintentionally,
because FCL1 still refers 'index' changed at (4)
The root cause of this issue is that there is no examination about
validity of filtered changelog cache against current unfiltered one.
This patch discards filtered changelog cache, if its 'index' object
isn't shared with unfiltered one.
BTW, at the time of this patch, redundant truncation of
'00changelog.i' at failure of transaction (see
0a7610758c42 for
detail) often prevents "hg serve" from making already rollbacked
revisions visible, because updating timestamps of '00changelog.i' by
truncation makes "hg serve" discard old repoview object with invalid
filtered changelog cache.
This is reason why this issue is overlooked before this patch, even
though test-bundle2-exchange.t has tests in similar situation: failure
of "hg push" via HTTP by pretxnclose hook on server side doesn't
prevent subsequent commands from looking up outgoing revisions
correctly.
But timestamp on the filesystem doesn't have enough resolution for
recent computation power, and it can't be assumed that this avoidance
always works as expected.
Therefore, without this patch, this issue might appear occasionally.
$ cat >> $HGRCPATH << EOF
> [extensions]
> blackbox=
> rebase=
> mock=$TESTDIR/mockblackbox.py
>
> [experimental]
> evolution = createmarkers
> EOF
Create a repo with some tags
$ hg init repo
$ cd repo
$ echo initial > foo
$ hg -q commit -A -m initial
$ hg tag -m 'test tag' test1
$ echo first > first
$ hg -q commit -A -m first
$ hg tag -m 'test2 tag' test2
$ hg -q up -r 0
$ echo newhead > newhead
$ hg commit -A -m newhead
adding newhead
created new head
$ hg tag -m 'test head 2 tag' head2
$ hg log -G -T '{rev}:{node|short} {tags} {desc}\n'
@ 5:2942a772f72a tip test head 2 tag
|
o 4:042eb6bfcc49 head2 newhead
|
| o 3:c3cb30f2d2cd test2 tag
| |
| o 2:d75775ffbc6b test2 first
| |
| o 1:5f97d42da03f test tag
|/
o 0:55482a6fb4b1 test1 initial
Trigger tags cache population by doing something that accesses tags info
$ hg tags
tip 5:2942a772f72a
head2 4:042eb6bfcc49
test2 2:d75775ffbc6b
test1 0:55482a6fb4b1
$ cat .hg/cache/tags2-visible
5 2942a772f72a444bef4bef13874d515f50fa27b6
042eb6bfcc4909bad84a1cbf6eb1ddf0ab587d41 head2
55482a6fb4b1881fa8f746fd52cf6f096bb21c89 test1
d75775ffbc6bca1794d300f5571272879bd280da test2
Hiding a non-tip changeset should change filtered hash and cause tags recompute
$ hg debugobsolete -d '0 0' c3cb30f2d2cd0aae008cc91a07876e3c5131fd22 -u dummyuser
$ hg tags
tip 5:2942a772f72a
head2 4:042eb6bfcc49
test1 0:55482a6fb4b1
$ cat .hg/cache/tags2-visible
5 2942a772f72a444bef4bef13874d515f50fa27b6 f34fbc9a9769ba9eff5aff3d008a6b49f85c08b1
042eb6bfcc4909bad84a1cbf6eb1ddf0ab587d41 head2
55482a6fb4b1881fa8f746fd52cf6f096bb21c89 test1
$ hg blackbox -l 5
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> 2/2 cache hits/lookups in * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> writing .hg/cache/tags2-visible with 2 tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> tags exited 0 after * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> blackbox -l 5
Hiding another changeset should cause the filtered hash to change
$ hg debugobsolete -d '0 0' d75775ffbc6bca1794d300f5571272879bd280da -u dummyuser
$ hg debugobsolete -d '0 0' 5f97d42da03fd56f3b228b03dfe48af5c0adf75b -u dummyuser
$ hg tags
tip 5:2942a772f72a
head2 4:042eb6bfcc49
$ cat .hg/cache/tags2-visible
5 2942a772f72a444bef4bef13874d515f50fa27b6 2fce1eec33263d08a4d04293960fc73a555230e4
042eb6bfcc4909bad84a1cbf6eb1ddf0ab587d41 head2
$ hg blackbox -l 5
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> 1/1 cache hits/lookups in * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> writing .hg/cache/tags2-visible with 1 tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> tags exited 0 after * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> blackbox -l 5
Resolving tags on an unfiltered repo writes a separate tags cache
$ hg --hidden tags
tip 5:2942a772f72a
head2 4:042eb6bfcc49
test2 2:d75775ffbc6b
test1 0:55482a6fb4b1
$ cat .hg/cache/tags2
5 2942a772f72a444bef4bef13874d515f50fa27b6
042eb6bfcc4909bad84a1cbf6eb1ddf0ab587d41 head2
55482a6fb4b1881fa8f746fd52cf6f096bb21c89 test1
d75775ffbc6bca1794d300f5571272879bd280da test2
$ hg blackbox -l 5
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> --hidden tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> 2/2 cache hits/lookups in * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> writing .hg/cache/tags2 with 3 tags
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> --hidden tags exited 0 after * seconds (glob)
1970/01/01 00:00:00 bob @2942a772f72a444bef4bef13874d515f50fa27b6 (5000)> blackbox -l 5