doc: clarify that https cert verification requires web.cacerts

url: verify correctness of https server certificates (issue2407) Pythons SSL module verifies that certificates received for HTTPS are valid according to the specified cacerts, but it doesn't verify that the certificate is for the host we connect to. We now explicitly verify that the commonName in the received certificate matches the requested hostname and is valid for the time being. This is a minimal patch where we try to fail to the safe side, but we do still rely on Python's SSL functionality and do not try to implement the standards fully and correctly. CRLs and subjectAltName are not handled and proxies haven't been considered. This change might break connections to some sites if cacerts is specified and the certificates (by our definition) isn't correct. The workaround is to disable cacerts which in most cases isn't much worse than it was before with cacerts.

test-subrepo-recursion: remove empty defaults section

mq: Removed extra ... in short help for qdelete Update to 57ad5c4e4213, which left a ... too much, after removing -r [REV]

mq: removed short option in help for deprecated options Removed help for deprecated short option for: -n NAME for qpush -n NAME for qpop -r REV for qdelete|qremove|qrm

test-subrepo-recursion: deleted default arguments Deleted default arguments from test-sub-repo-recursion. Rationale is that it is confusing to read, when the arguments aren't at each command in the test

tests: removed test names in tests The name of the test files is replaced with a glob * expression, thereby the tests does not depend on the filename of the file they are in.

tests: fix 05210e955bef merge error in test-git-import.t

test-convert-cvs-detectmerge: add sleep so cvs notices changes

init: expand destination url as a configured paths Most commands expands configured paths when repositories are specified, just as the urls help says. Clone also expands the destination path. Clone is morally equivalent to init + push/pull, so init should also expand the destination path - and that is what this patch makes it do. There is no really good usecases for this and in most cases it doesn't matter, but consistency is nice, and otherwise we would have to document the exception.

mq: explain qpush -f better

serve: let --web-conf help reference hgweb

transplant: add the transplanted revset predicate This adds support to identify a particular transplanted changeset or set of changesets. The argument is optional. Examples: hg log -r 'transplanted(1234 or 2345)' hg log -r 'transplanted()'

test-convert-cvs-branch: add sleep so cvs notices changes

graphlog: style with header and footer (issue2395) The glog command didn't emit header and footer from the style, as demonstrated by "hg glog --style xml". Asciiart combined with xml markup hardly makes sense, but header and footer might however be useful for adding for example html pre tags around the graph.

test-serve: use service that works on more platforms Follow-up to ba8850911703: echo is ambiguous on OS/X, and Solaris have neither http nor gopher. daytime seems to be available everywhere.

Merge with stable

patch: test and document a bit binary to regular file upgrade

patch: upgrade to git patch when removing binary file Otherwise it may cause data loss when removing binary files in mq with --git=auto.

patch: fix rename text to binary file (issue2400)

tests: show skip reason instead of "irrelevant" with unified tests, too parsehghaveoutput expects just the test output, not the merged test/output, so for skipped unified tests e.g.: Skipped test-convert-darcs.t: missing feature: irrelevant was shown instead of: Skipped test-convert-darcs.t: missing feature: darcs client

merge with stable

merge with iin

Correct Content-Type header values for archive downloads. The content type for both .tar.gz and .tar.bz2 downloads was application/x-tar, which is correct for .tar files when no Content-Encoding is present, but is not correct for .tar.gz and .tar.bz2 files unless Content-Encoding is set to gzip or x-bzip2, respectively. However, setting Content-Encoding causes browsers to undo that encoding during download, when a .gz or .bz2 file is usually the desired artifact. Omitting the Content-Encoding header is preferred to avoid having browsers uncompress non-render-able files. Additionally, the Content-Disposition line indicates a final desired filename with .tar.gz or .tar.bz2 extension which makes providing a Content-Encoding header inappropriate. With the current configuration browsers (Chrome and Firefox thus far) are registering the application/x-tar Content-Type and not .tar extension and appending that extension, yielding filename.tar.gz.tar as a final on-disk artifact. This was originally reported here: http://stackoverflow.com/questions/3753659 I've changed the .tar.gz and .tar.bz2 Content-Type values to application/x-gzip and application/x-bzip2, respectively. Which yields correctly named download artifacts on Firefox, Chrome, and IE.

merge with iin

i18n-pt_BR: update to new Portuguese ortography

i18n-pt_BR: minor rewording

i18n-pt_BR: assorted typo fixes

merge with i18n

i18n-pt_BR: synchronized with 84ceedcfeb6a