branchmap: display filtername when `updatebranch` fails to do its jobs
We have a very handy assert at the ends of `branchmap.updatecache` that check
the resulting branchmap is actually valid.
I know we do not like assert in mercurial but this one is very handy for
debugging. There is really not reason for `branchmap.updatecache` to have this
kind of issue but this happened and handful of time during the development of
this or introduction of other related feature. I advice to keep it around until
we are a bit more confident with the new code.
run-tests.py: don't let hg run interactively in debug mode
In normal test mode stdin is closed and hg is thus not interactive. In --debug
mode stdin is inherited from the running console and to the tests, and hg could
thus wait in prompts when running on Windows.
See http://selenic.com/pipermail/mercurial-devel/2013-January/047548.html .
Instead set ui.interactive=False to make Mercurial non-interactive. Other
commands might still work differently in the --debug environment.
This should solve the problem with hg waiting for input but still make it
possible to add --debugger to hg in a test and run run-tests.py with --debug.
run-tests.py: backout "don't use console for stdin when running in debug mode"
f5842787a958 caused that some kind of interactive debugging no longer was
possible - such as running hg with --debugger in a test run with run-tests.py
--debug .
rebase: properly handle unrebased revision between rebased one
With rebase taking multiple roots it is possible to have revision in the "rebase
domain" not rebased themself. We do not want rebased revision above them to be
detached. We want such revision to be rebased on the nearest rebased ancestors.
This allows to preserve the topology of the rebase set as much a possible
To achieve this we introduce a new state `revignored` which informs
`defineparents` of the situation.
The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.
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.
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.