context: grudging accept longs in constructor

win32: fix encoding handling for registry strings (issue3467) This stopped handling non-ASCII strings in 1.8

mpatch: use Py_ssize_t for string length

mpatch: use Py_ssize_t Eliminates mpatch.c(73) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data mpatch.c(299) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(321) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(335) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(346) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

subrepo: make subrepo.subrepo(<not a subrepo path>) fail Until now, when calling subrepo.subrepo with a path at which there is no subrepo, a "nullstate" tuple would be returned. However, this is not very useful (the tuple can't really be used for creating a subrepo), so we'd just as soon have the function just fail, and leave it up to the caller to decide what to do. The motivation for doing this now is to simplify the solution for (issue3056).

merge with stable

hgweb: use ui.nontty to disable all cooked I/O

progress: use ui._isatty

pager: use ui._isatty infrastructure

ui: add _isatty method to easily disable cooked I/O

bdiff: check and cast first parameter value on putbe32() calls Eliminates mercurial/bdiff.c(383) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(384) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uint32_t', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

bdiff: use Py_ssize_t instead of int Reduces the conversion warnings mercurial/bdiff.c(61) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(307) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/bdiff.c(308) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/bdiff.c(362) : warning C4244: '+=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(380) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(381) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(382) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(416) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data to mercurial/bdiff.c(383) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(384) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uint32_t', possible loss of data on the three putbe32() calls in the function bdiff when compiling for Windows x64 target using the Microsoft compiler.

doc: add detail explanation for 'present()' predicate of revsets

osutil: handle deletion race with readdir/stat (issue3463)

merge with stable

branchcache: backout 0311a6abd38a

dispatch: try and identify third-party extensions as sources of tracebacks Extension authors should explicitly declare their supported hg versions and include a buglink attribute in their extension. In the event that a traceback occurs, we'll identify the least-recently-tested extensionas the most likely source of the defect and suggest the user disable that extension. Packagers should make every effort to ship hg versions from exact tags, or with as few modifications as possible so that the versioning can work appropriately.

hgext: mark all first-party extensions as such

bookmarks: test that bare update forwards active bookmark

keyword: intentionally ignore check-code warning about unwrapped ui message

help: include bookmarks in 'help revisions' and simplify wording

merge with i18n

i18n-ru: synchronized with b490be1fec06

i18n-ru: correct `push --new-branch` description

bundle: make bundles more portable (isue3441) This is achieved by acting as if the user had given -r<rev> for each head rev of outgoing changesets on the command line, as well as appropriate --base <rev>. The discovery information is computed as normal, and then adjusted as above.

revset: fix traceback for bogus revisions in id(rev) hg log -r "id(1234567)" now returns an empty list like rev() does.

Makefile: remove generated mercurial/__version__.py

mq: rename --check into --keep-changes I named it --check because it felt like qpush & co were checking *more* things to ensure local changes could not be lost. But it has been pointed on the mailing list that --check is already used by update command with a meaning almost opposite to this one. An alternative was --keep but qfold and qdelete already have such an option to preserve patch files and qfold may be a candidate for --check. - qpush/qpop/qgoto --check becomes --keep-changes. - mq.check becomes mq.keepchanges. - The short option -c is dropped as -k may conflict with existing --keep. The availabilitity of mq.keepchanges should not make this too painful. - Fix minor reST mistake in option description.

parsers: use Py_CLEAR where appropriate

largefiles: fix addremove when largefile is missing (issue3227)