Christian Ebert <blacktrash@gmx.net> [Sat, 19 Jan 2013 09:40:50 +0000] rev 1205
Merge with stable
Mads Kiilerich <madski@unity3d.com> [Fri, 18 Jan 2013 01:23:51 +0100] rev 1204
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.
[ original upstream message ]
Mads Kiilerich <madski@unity3d.com> [Fri, 18 Jan 2013 01:16:16 +0100] rev 1203
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 .
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Wed, 16 Jan 2013 20:56:02 +0000] rev 1202
Merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 14:26:19 +0100] rev 1201
get-with-headers: add a --headeronly switch
In some case we do not care about the actual rendering.
[ original upstream message ]
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 02:01:11 +0100] rev 1200
tests: make test-hgweb.t output stable
Instability introduced in combination of a4d7fd7ad1f7 and e389a25e7e60.
[ original upstream message ]
Mads Kiilerich <madski@unity3d.com> [Tue, 15 Jan 2013 20:54:57 +0100] rev 1199
serve: don't send any content headers with 304 responses
Fixes HTTP protocol violation introduced in cf5c76017e11. 'hg serve' would show
a stacktrace when loading pages that not had been modified.
There was test coverage for this, but the wrong response headers wasn't shown
and thus not detected.
[ original upstream message ]
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 00:09:26 +0100] rev 1198
destroyed: drop complex branchcache rebuilt logic
The strip code used a trick to lower the cost of branchcache update after a
strip. However is less necessary since we have branchcache collaboration.
Invalid branchcache are likely to be cheaply rebuilt again a near subset of the
repo.
Moreover, this trick would need update to be relevant in the now filtered
repository world. It currently update the unfiltered branchcache that few people
cares about. Make it smarter on that aspect would need complexes update of the
calling logic
So this mechanism is:
- Arguably needed,
- Currently irrelevant,
- Hard to update
and I'm dropping it.
We now update the branchcache in all case by courtesy of the read only reader.
This changeset have a few expected impact on the testsuite are different cache
are updated.
[ original upstream message ]
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 00:08:08 +0100] rev 1197
branchmap: update cache of 'unserved' filter on new changesets
The `commitctx` and `addchangegroup` methods of repo upgrade branchcache after
completion. This behavior aims to keep the branchcache in sync for read only
process as hgweb. See ee317dbfb9d0 for details.
Since changelog filtering is used, those calls only update the cache for unfiltered repo.
One of no interest for typical read only process like hgweb.
Note: By chance in basic case, `repo.unfiltered() == repo.filtered('unserved')`
This changesets have the "unserved" cache updated instead. I think this is the
only cache that matter for hgweb.
We could imagine updating all possible branchcaches instead but:
- I'm not sure it would have any benefit impact. It may even increase the odd of
all cache being invalidated.
- This is more complicated change.
So I'm going for updating a single cache only which is already better that
updating a cache nobody cares about.
This changeset have a few expected impact on the testsuite are different cache
are updated.
[ original upstream message ]
Mads Kiilerich <madski@unity3d.com> [Tue, 15 Jan 2013 23:30:10 +0100] rev 1196
tests: run with PYTHONHASHSEED=random
Python set and dict iteration order is in principle undefined but usually
'quite stable'. Setting PYTHONHASHSEED=random will make the iteration order
more random in Python 2.6.8 and 2.7.3 and where it has been backported. This
can thus help spot dependencies on undefined behaviour and prevent future
problems.
[ original upstream message ]