bookmarks: reuse @number bookmark, if it refers changeset referred remotely Before this patch, "@number" suffixed bookmark may be newly created at each "hg pull" from the remote repository, if the bookmark in remote repository diverges from one in local one. This causes unexpected increase of "@number" suffixed bookmarks. This patch reuses "@number" suffixed bookmark, if it refers the changeset which is referred by the same bookmark in the remote repository.

bookmarks: check @pathalias suffix before available @number for efficiency Before this patch, available "@number" suffix is searched before "@pathalias" suffix, even though the latter has higher priority than the former if the latter exits. This patch checks "@pathalias" suffix before available "@number" for efficiency. When an URL has multiple path definitions, the first one is used for "pathalias" after this patch, even though the last one is used before this patch, because: - this choice can terminate loop immediately for efficiency - such case seems to be rare

bookmarks: prevent divergent bookmark from being updated unexpectedly Before this patch, "@99" suffixed bookmark may be updated unexpectedly by the bookmark value on the remote side at "hg pull", if all of "@1" to "@99" suffixed bookmarks exist in the local repository, because variable "n" still refers "@99" suffixed bookmark after the loop to examine "@num" suffixes, even though it already exists in the local repository. This patch prevents divergent bookmark from being updated unexpectedly, and shows warning message in such situation. This patch uses original python script "seq.py" instead of "seq" command to create sequence numbers in the test, because "seq" command may not be available: it isn't defined in recent POSIX specification (POSIX.1-2001 2013 Edition or XPG7)

manifest: include Python.h before standard headers Python.h should be included before any standard headers according to the python docs: https://docs.python.org/2/c-api/intro.html#include-files

crecord: use colwidth instead of ucolwidth

manifest: speed up matches for large sets of files If the number of files being matched is large, the bisection overhead can dominate, which caused a performance regression for revert --all and histedit. This introduces a (fairly arbitrary) cross-over from using bisections to bulk search.