Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Jan 2013 23:21:32 +0100] rev 18446
rebase: lose the comparison to `nullmerge`
For a proper behavior of the `--rev` revision we will need another possible
state for revision ignored by rebase. We alter the comparison to `nullmerge`
to match this future lower state too.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 18 Jan 2013 23:43:32 +0100] rev 18445
repoview: cache filtered changelog
Creating a new changelog object for each access is costly and prevents efficient
caching changelog side. This introduced a x5 performance regression in log
because chunk read from disk were never reused. We were jumping from about 100
disk read to about 20 000.
This changeset introduce a simple cache mechanism that help the last changelog
object created by a repoview. The changelog is reused until the changelog or the
filtering changes.
The cache invalidation is much more complicated than it should be. But MQ test
show a strange cache desync. I was unable to track down the source of this
desync in descent time so I'm not sure if the issue is in MQ or core. However
given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route
that makes the cache mechanism safer.