hgwebdir: use template paths configured in the hgrc (issue2281)

changegroup*(): use set instead of dict

Merge with stable

bash/zsh completion: use HGPLAIN when invoking hg (issue2297)

patch: fix extract() docstring, it returns branch as well

merge with stable

doc: remove has_key usage in hgmanpage

gendoc: remove callable usage (check-code)

bookmarks: rewrite _bookmarks method documentation

init: create target directory recursively Subrepos with relative paths must often be cloned to locations deep in the directory structure. This allows clone over ssh (init+push) work.

doc: make sure we use our own code for generating man pages docutils would in some situations pick up its own manpage.py instead of doc/manpage.py. Renaming to hgmanpage.py makes it less ambiguous.

transplant: crash if repo.commit() finds nothing to commit (makes issue2135, issue2264 more obvious, but does nothing to fix either one) This seems to happen in two distinct cases: * patch.patch() claims success but changes nothing (e.g. the transplanted changeset adds an empty file that already exists) * patch.patch() makes changes, but repo.status() fails to report them Both of these seem like bugs in other parts of Mercurial, so arguably it's not transplant's job to detect the failure to commit. However: * detecting the problem as soon as possible is desirable * it prevents a more obscure crash later, in transplants.write() * there might be other lurking (or future) bugs that cause repo.commit() to do nothing Also, in the case of issue2264 (source changesets silently dropped by transplant), the only way to spot the problem currently is the crash in transplants.write(). Failure to transplant a patch should abort immediately, whether it's user error (patch does not apply) or a Mercurial bug (e.g. repo.status() failing to report changes).

mq: cleanup status if applied mq is stripped (issue1881) stripping of applied mq patches leads to wrong state recorded in status file. find all mq patches that will be affected and clean up status file before strip.

bundle: lookup revisions after addbranchrevs When addbranchrevs extends revs, it adds changeset hashes, and not node ids. Which means that we have to lookup for revisions _after_ the addbranchrevs call, instead of before.

log: do not redefine cachefunc in walkchangerevs The same variable is defined a few blocks earlier. The first phases in walkchangerevs should in fact fill that cache, and allow faster lookups in the last phase. Redefining and overriding this cached function, (knowing that it will be called with the same arguments) defeats the caching purpose.

cmdutils: fix code style

contrib: add debugshell extension

log: document the different phases in walkchangerevs

log: slowpath: only walk specified revision range during preparation Even with --removed, it does not make sense to examine changesets outside of the revision range that was specified by the user: the last phase only yields a subset of (revs), preparation phase hence only has to examine (revs) to fill correctly fncache.

Merge with stable

revert: rename original to .orig instead of copying (issue2282) By renaming before reverting the content of the file we ensure that we handle and break hardlinks properly. Handling of other hardlinks to .orig is somebody elses problem.

inotify: make inotifydirstate.status() returns a tuple of lists. This makes it consistent with dirstate.status(), which is important if there are other extensions messing with the output of status(). Those extensions can safely assume that dirstate.status() returns a tuple of lists, because its docstring says it does. But inotifystatus.dirstate() returns a list of lists, which can break those other extensions.

protocol: move the streamclone implementation into wireproto

protocol: use generators instead of req.write() for hgweb stream responses

protocol: wrap non-string protocol responses in classes

protocol: convert StreamException to generated error code This makes it much easier to handle these errors at the transport level.

protocol: extract compression from streaming mechanics

protocol: rename send methods to get grouping by prefix

protocol: shuffle server methods to group send methods

protocol: do not translate error messages on the remote side

protocol: use return shortcut instead of respond function

protocol: command must be checked before passing in

tests: rename some tests to help grouping

keyword: add extra datefilters in a single update call

Merge with stable

Merge with main

cmdutil: fix accidental name clash with revrange function The revrange function was used further up, and when a local variable is defined with the same name, the earlier call to revrange becomes a 'local variable used before assignment' error. The clash was introduced in 890ad9d6a169.

commands: fix update's help to be more accurate Branches can have multiple heads, so it doesn't make sense to speak of "the head of the current branch". What update really does is try to update to the *tip* of the current branch.

i18n: use encoding.colwidth() for correct column width Some encoding and language combinations (e.g.: UTF-8 and Japanese) cause encoding characters into sequence of bytes more than column width of them. So, encoding.colwidth() should be applied instread of len() on i18n strings. In addition to it, formatting by '%*s'/'%-*s' also uses "number of bytes" to calculate space padding size, and should be fixed, too.

merge with stable

log: slowpath: do not read the full changelog When in the slowpath, we are examining _all_ changesets in revs. We need to order reads so they happen increasingly for I/O performance. Increasing windows were used to read changelog backwards in a windowed manner, reading the changelog forward inside each window. But since no revision range was specified, it was equivalent to reading the full changelog, even if a single revision was passed to the commandline. When --removed is used, we _need_ to scan all changesets, but if we're only looking for file patterns, this is not necessary and we can stick to the revspec that was given to us.

log: remove increasing windows usage in fastpath The purpose of increasing windows is to allow backwards iteration on the filelog at a reasonable cost. But is it needed? - if follow is False, we have no reason to iterate backwards. We basically just want to walk the complete filelog and yield all revisions within the revision range. We can do this forward or backwards, as it only reads the index. - when follow is True, we need to examine the contents of the filelog, and to do this efficiently we need to read the filelog forward. And on the other hand, to track ancestors and copies, we need to process revisions backwards. But is it necessary to use increasing windows for this? We can iterate over the complete filelog forward, stack the revisions, and read the reversed(pile), it does the same thing with a more readable code.

log: refactor: test for ranges inside filerevgen

log: refactor: compute the value of last outside of filerevgen

context: use os.lstat instead of os.stat to fetch file size When file is a link, we want the size of the link itself, not the size of the file it points to.

check-code: add --blame switch

changegroupsubset: remove unneeded cast to list

check-code: catch dict.has_key

Merge with stable

mark ui.warn strings for translation

check-code: warn about untranslated ui.warn calls

localrepo: remove push_{unbundle,addchangegroup}(), factor it inside push()

wireproto: refactor list of nodeid encoding / decoding

ssh: drop some old imports

protocol: move hgweb protocol support back into protocol.py - introduce iscmd - simplify error handling - remove unneeded imports

protocol: unify server-side capabilities functions

protocol: unify unbundle on the server side

protocol: unify client unbundle support - introduce _callpush helper - factor out differences in result handling into helpers - unify

protocol: unify client changegroup methods

protocol: convert some ssh abort calls