Fri, 18 Jan 2013 01:16:16 +0100 run-tests.py: backout "don't use console for stdin when running in debug mode" stable
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 ]
Wed, 16 Jan 2013 20:56:02 +0000 Merge with stable
Christian Ebert <blacktrash@gmx.net> [Wed, 16 Jan 2013 20:56:02 +0000] rev 1202
Merge with stable
Wed, 16 Jan 2013 14:26:19 +0100 get-with-headers: add a --headeronly switch 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 ]
Wed, 16 Jan 2013 02:01:11 +0100 tests: make test-hgweb.t output stable stable
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 ]
Tue, 15 Jan 2013 20:54:57 +0100 serve: don't send any content headers with 304 responses stable
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 ]
Wed, 16 Jan 2013 00:09:26 +0100 destroyed: drop complex branchcache rebuilt logic stable
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 ]
Wed, 16 Jan 2013 00:08:08 +0100 branchmap: update cache of 'unserved' filter on new changesets stable
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 ]
Tue, 15 Jan 2013 23:30:10 +0100 tests: run with PYTHONHASHSEED=random stable
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 ]
Tue, 15 Jan 2013 13:33:28 -0800 run-tests: exit cleanly if parallel run is interrupted stable
Bryan O'Sullivan <bryano@fb.com> [Tue, 15 Jan 2013 13:33:28 -0800] rev 1195
run-tests: exit cleanly if parallel run is interrupted If interrupted while running with "--jobs N", run-tests asynchronously spewed a bunch of output and backtraces from both the master and slave processes, leaving the terminal full of goop. This patch makes it behave more sensibly. [ original upstream message ]
Sun, 13 Jan 2013 01:39:16 -0600 filtering: rename filters to their antonyms stable
Kevin Bullock <kbullock@ringworld.org> [Sun, 13 Jan 2013 01:39:16 -0600] rev 1194
filtering: rename filters to their antonyms Now that changelog filtering is in place, it's become evident that naming the filters according to the set of revs _not_ included in the filtered changelog is confusing. This is especially evident in the collaborative branch cache scheme. This changes the names of the filters to reflect the revs that _are_ included: hidden -> visible unserved -> served mutable -> immutable impactable -> base repoview.filteredrevs is renamed to filterrevs, so that callers read a bit more sensibly, e.g.: filterrevs('visible') # filter revs according to what's visible [ original upstream message ]
(0) -1000 -300 -100 -10 +10 +100 tip