Mercurial > public > mercurial-scm > hg
diff mercurial/phases.py @ 18983:31bcc5112191
destroyed: invalidate phraserevs cache in all case (issue3858)
When revisions are destroyed, the `phaserevs` cache becomes invalid in most case.
This cache hold a `{rev => phase}` mapping and revision number most likely
changed.
Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets
destruction. When some roots are filtered the `phaserevs` cache is invalidated.
But not if none root where destroyed.
We now invalidate the cache in all case filtered root or not.
This bug was a bit tricky to reproduce as in most case we either:
* rebase a set a draft changeset including root (phaserev invalidated)
* strip tip-most changesets (no re-numbering of revision)
Note that the invalidation of `phaserevs` are not strictly needed when only
tip-most part of the history have been destroyed. But I do not expect the
overhead to be significant.
author | Pierre-Yves David <pierre-yves.david@logilab.fr> |
---|---|
date | Mon, 15 Apr 2013 17:10:58 +0200 |
parents | 767d1c602c8b |
children | d51c4d85ec23 |
line wrap: on
line diff
--- a/mercurial/phases.py Mon Apr 15 01:59:11 2013 +0200 +++ b/mercurial/phases.py Mon Apr 15 17:10:58 2013 +0200 @@ -266,7 +266,15 @@ filtered = True if filtered: self.dirty = True - self._phaserevs = None + # filterunknown is called by repo.destroyed, we may have no changes in + # root but phaserevs contents is certainly invalide (or at least we + # have not proper way to check that. related to issue 3858. + # + # The other caller is __init__ that have no _phaserevs initialized + # anyway. If this change we should consider adding a dedicated + # "destroyed" function to phasecache or a proper cache key mechanisme + # (see branchmap one) + self._phaserevs = None def advanceboundary(repo, targetphase, nodes): """Add nodes to a phase changing other nodes phases if necessary.