localrepo: filter unknown nodes from the phasecache on destroyed
When commit is followed by strip (qrefresh), phasecache contains nodes that were
removed from the changelog. Since phasecache is filecached with .hg/store/phaseroots
which doesn't change as a result of stripping, we have to filter it manually.
If we don't write it immediately, the next time it is read from disk the nodes
will be filtered again. That's what happened before, but there's no reason not
to write it immediately.
The change in test-keyword.t is caused by the above.
--- a/mercurial/localrepo.py Fri Jan 04 06:11:29 2013 +0100
+++ b/mercurial/localrepo.py Fri Dec 21 17:19:52 2012 +0100
@@ -1425,6 +1425,18 @@
cache.update(self, ctxgen)
cache.write(self)
+ # When one tries to:
+ # 1) destroy nodes thus calling this method (e.g. strip)
+ # 2) use phasecache somewhere (e.g. commit)
+ #
+ # then 2) will fail because the phasecache contains nodes that were
+ # removed. We can either remove phasecache from the filecache,
+ # causing it to reload next time it is accessed, or simply filter
+ # the removed nodes now and write the updated cache.
+ if '_phasecache' in self._filecache:
+ self._phasecache.filterunknown(self)
+ self._phasecache.write()
+
# Ensure the persistent tag cache is updated. Doing it now
# means that the tag cache only has to worry about destroyed
# heads immediately after a strip/rollback. That in turn
--- a/tests/test-keyword.t Fri Jan 04 06:11:29 2013 +0100
+++ b/tests/test-keyword.t Fri Dec 21 17:19:52 2012 +0100
@@ -578,7 +578,6 @@
$ hg --debug commit -ma2c -d '1 0' -u 'User Name <user@example.com>'
c
c: copy a:0045e12f6c5791aac80ca6cbfd97709a88307292
- removing unknown node 40a904bbbe4c from 1-phase boundary
overwriting c expanding keywords
committed changeset 2:25736cf2f5cbe41f6be4e6784ef6ecf9f3bbcc7d
$ cat a c
@@ -749,7 +748,6 @@
$ hg --debug commit -l log -d '2 0' -u 'User Name <user@example.com>'
a
- removing unknown node 40a904bbbe4c from 1-phase boundary
overwriting a expanding keywords
committed changeset 2:bb948857c743469b22bbf51f7ec8112279ca5d83
$ rm log