hgweb: move hex creation into an object method This is clearer and allow later overwrite.

hgweb: pass nodefunc to the revnav object The issue between hgweb and filtering lay in this function. Moving it into the object itself helps to abstract the erroneous bit.

hgweb: move revnavgen into an object For later compatibility with changelog filtering some part of the navigation generation logic will be altered. Those altered part will be different when in the changelog case and in the filelog case. Moving this into an object will allow to use inheritance to override just the part of the logic we need. The aimed logic are for example: - generation of revision 'hex' (different logic for changelog and filelog) - revlog emptyness test - fetching of the first revision of a revlog (may not be 0)

hgweb: `limit` argument is actually `latestonly` renames and enforce The `limit` argument of several generator have only two possible values in practice: 0 and 1. We rename this parameter to `latestonly` and simplify it's handling. The simplification allows us to save fetching of data that we are sure to not consume. Having a function minimal function perimeter will helps future refactoring.

hgweb: add test regarding filtering and hgweb Since 4d1671b39168 hgweb is broken with filtering. This changeset add test that should pass once it is fixed. Test currently broken are commented and will be uncommented by changeset that fix them. The filelog test is currently passing because we already have some hack in core regarding filelog (see 518c1403838f).

get-with-headers: add a --headeronly switch In some case we do not care about the actual rendering.

tests: more comment cleanup related to obsolescence

test: fix in-test comments related to obsolescence The `ui.prevent-unstable` option never made it into core. It always behaves this way when obsolescence feature is enabled. See changesets c5bd753c5bc6, bacf55bd8f90 and 0f5a0a2073a8 for details.

stream_in: write the remote branchcache for a usage as wide as possible Writing cache for unfiltered repo only is barely useful, Most repo user are now at least use the `hidden` filter. This changeset now assigns the remote cache for a filter as low as possible for a wider reuse as possible.

destroyed: update `unserved` branchcache instead Before this changesets the `destroyed` function updated the branchcache for unfiltered repository. As seen in a previous changeset, Read only repo does not cares about the unfiltered repo. We now update it for `unserved`.

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.

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.

tests: make test-hgweb.t output stable Instability introduced in combination of a4d7fd7ad1f7 and e389a25e7e60.

hgweb: ensure _navseq yield strictly increasing numbers This is not hard and allows to drop hack in the customer code.

hgweb: better names for _navseq arguments The old names were misleading.

hgweb: drop recursivity in _navseq This is totally not needed.

hgweb: move the `seq` function out of the revnavgen scope There is not reason for it to be a in there. And this function could use a major reworks.

hgweb: simplify return value creation in for navgen We now have access to better syntax allowing a clearer version.

hgweb: do not access first changeset with a string There is not reason not to use an int

refactoring: use unlinkpath with ignoremissing

docs: "deprecate" checkchanged and checkconflicts in merge-tool configuration These settings were replaced by check=changed and check=conflicts in a912f26777d3. There is no reason to announce two different ways to achieve the same. The old way should be kept but not announced.

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.

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.

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

clone: don't include empty revlogs in stream

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.

tests: fix doctest stability over Python versions pprint ain't pretty in Python 2.4: Changed in version 2.5: Dictionaries are sorted by key before the display is computed; before 2.5, a dictionary was sorted only if its display required more than one line, although that wasn’t documented. Fixes issue introduced in 404feac78b8a.

tests: stabilize doctest output Avoid dependencies to dict iteration order.

tests: make test-hook.t output more stable

convert: make toposort order stable when multiple orderings are possible The output of some tests are changed. Not necessarily to the better, just other valid permutations.

convert: report cvsps branchpoints sorted

convert: process subversion branch in a sorted order

convert: process missing branches in sorted order

convert: process splicemap in sorted order

mq: stabilize update after strip of parent revision Strip will (if it updates) update to the parent of revs[0], where revs are the roots of the tree that is stripped. When revs was list(set) it was thus undefined which root parent it would update to. With sorted(set) it is at least stable what it updates to. (But it is very possible that another more useful and predictable behaviour could be defined ... such as updating to the tip-most surviving wd ancestor.)

histedit: process bookmarks in sorted order

churn: sort users with same churn by name This makes the output order well-defined and improves code readability.

largefiles: upload files in sorted order

hgweb: generate query strings with parameters sorted by key

identity: report bookmarks sorted

obsolete: process markers in a stable order Using set iteration order gave unstable debugsuccessorssets output with PYTHONHASHSEED=random.

subrepos: process subrepos in sorted order Add sorted() in places found by testing with PYTHONHASHSEED=random and code inspection. An alternative to sprinkling sorted() all over would be to change substate to a custom dict with sorted iterators...

bookmarks: process pulled remote bookmarks in sorted order

copies: report found copies sorted

discovery: process heads in sorted order

merge: process files in sorted order

commandserver: report capabilities sorted

bisect: store state sorted

localrepo: store branchheads sorted

localrepo: store requirements sorted

copies: make the loss in _backwardcopies more stable A couple of tests shows slightly more correct output. That is pure coincidence.

serve: use chunked encoding in hgweb responses 'hg serve' used to close connections when sending a response with unknown length ... such as a bundle or archive. Now chunked encoding will be used for responses with unknown length, and the connection do thus not have to be closed to indicate the end of the response. Chunked encoding is only used if the length is unknown, if the connection wouldn't be closed for other reasons, AND if it is a HTTP 1.1 request. This will not benefit other users of hgweb ... but it can serve as an example that it can be done.

serve: remove connection close hack for Python 2.3 Introduced in 276de216d2c5 and no longer needed - BaseHTTPServer handles connection closing just fine if we don't mess with its internals.

hgweb: pass the actual response body to request.response, not just the length This makes it less likely to send a response that doesn't match Content-Length.

hgweb: don't pass empty response chunks on hgweb internals will often produce empty writes - especially when returning compressed data. hgweb is no middleware application and there is thus no reason to pass them on to be processed in other layers.

hgweb: remove handling of any else than strings from request.write Iterators should be returned WSGI style, not written. And apparently all of hgweb do that.