obsolete: let N denote number of obsoleted changestes in a marker The number of obsoleted changesets is referred to as N later in the docstring.

obsolete: fix language and grammar in module docstring

churn: compute padding with unicode strings Most UTF-8 aware terminals convert multibyte sequences into a single displayed characters. Because the first column is padded by counting bytes, the second column is not perfectly aligned in the presence of non ASCII characters.

Added signature for changeset 564f55b25122

Added tag 3.0-rc for changeset 564f55b25122

merge default into stable for 3.0 code freeze

bundle2: allow extensions to extend the getbundle request We want extensions to be able to request extra parts.

bundle2: add a way to add parts during a `getbundle` request We add a hook function to let extensions add parts to the bundle.

getbundle: pass arbitrary arguments all along the call chain The wireprotocol command accepts arbitrary arguments, we are now passing such arguments down the call chain.

bundle2: call a hook after the transaction is closed We call a dedicated hook right after closing the transaction. This will let people react to the transaction with all the information in hand. This hook is experimental and will not survive in future versions.

bundle2: call a hook prior to closing the transaction We call a dedicated hook right before closing the transaction. This will let people abort unbundling with all the information in hand. This hook is experimental and will not survive in future versions.

bundle2: inform transaction that we are in a bundle2 unbundle That way, hooks called during the unbundle process are aware that a bigger picture is going on.

changegroup: use tr.hookargs when calling changegroup hooks So that other parties using the transaction can put information in our hook calls.

changegroup: use tr.hookargs when calling pretxnchangegroup hooks So that other parties using the transaction can put information in our hook calls.

addchangegroup: register data in tr.hookargs We are registering data related to the process into the transaction hook data. This lets other parties using the same transaction get informed of the addchangegroup result.

transaction: add a notion of hook arguments It is now possible to register parameters to be used when invoking hooks in this transaction. This will cope with the fact that bundle2 adds multiple data types in a single transaction. Do not expect any wide and consistent usages of this in the next release. This will be used by bundle2 experiments first. It will be made better for the release after.

bundle2: allow extensions to plug into the push process Extensions are offered functions to add parts and process their results.

bundle2: require both client and server to opt in Even if the server is bundle2-enabled, the client now has to opt-in in the config too.

bundle2: move bundle2 config option to section "experimental" We highlight the fact that this is experimental by moving it to an "experimental" section, and we match the config name with the server capability name `bundle2-exp`.

bundle2: move all parts into a `bx2` namespace All currently core parts are moved to a `bx2` namespace (for "bundle 2 experimental"). This should avoid conflicts between the final stable format and the one about to be released.

bundle2: rename server capability to bundle2-exp For the same reason, we advertise this bundle2 implementation and format as experimental. This will leave room for field testing in 3.0 but won't conflict with a stable implementation in 3.1.

bundle2: use HG2X in the header The current implementation of bundle2 is still very experimental and the 3.0 freeze is yesterday. The current bundle2 format has never been field-tested, so we rename the header to HG2X. This leaves the HG20 header available for real usage as a stable format in Mercurial 3.1. We won't guarantee that future mercurial versions will keep supporting this `HG2X` format.

bundle2: transmit capabilities to getbundle during pull Bundle2 capabilities of the client are sent to the server in the bundlecaps argument of `getbundle`.

bundle2: include client capabilities in the pushed bundle The necessary data is now included in the `replycaps` part.

bundle2: advertise bundle2 caps in server capabilities We can now retrieve them from the server during push. The capabilities are encoded the same way as in `replycaps` part (with an extra layer of urlquoting to escape separators).

bundle2: add bundle2caps dict on localrepo object This dictionary will hold bundle2-related capabilities.

bundle2: capabilities encoding

bundle2: extract capabilities decoding We'll need to reuse this in more places (at least pull and push).

bundle2: protect capabilities name and values with url quoting This lift limitations of the text based encoding.

bundle2: support for capabilities with values The capabilities attributes of `bundle20` is now a dictionary and the reply caps can encode capabilities with values.

bundle2: add capabilities support in `replycaps` part This part now contains a list of supported capabilities.

bundle2: adds a capabilities attribute on bundler20 This attribute conveys the capabilities supported by the destination of the bundle. It is used to decide which parts to include in the bundle. This is currently a set but will probably be turned into a dictionary to allow capabilities with values.

bundle2: include stderr when capturing handlers output We do not discriminate between stdout and stderr yet. But this will do for now.

ui: pushbuffer can now also capture stderr We need an easy way to capture both stderr and stdout during bundle2 processing of a remote bundle. This changeset adds simple changes to the `ui` class to make this possible. I expect the interface to change in future releases as bundle2 will probably want to distinguish stdout and stderr. The current change will, however, do for now.

bundle2: capture remote stdout while unbundling When a reply is built, the bundle processing will capture the output of each handler and sends it to the client in a dedicated part. As a side effect, this add a "remote: " prefix to destination output on local push. This is considered okay for now as: 1. bundle2 is still experimental, 2. Matt said he could be okay to change output for bundle2, 3. This keeps the implementation simple. This changeset does it for stdout only. stderr will be done in a future changeset.

bundle2: introduce `replycaps` part for on-demand reply The bundle2 processing does not create a bundle2 reply by default anymore. It is only done if the client requests it with a `replycaps` part. This part is called `replycaps` as it will eventually contain data about which bundle2 capabilities are supported by the client. We have to add a flag to the test command to control whether a reply is generated or not.

bundle2: use an official iterparts method to unbundle parts Explicit is better than implicit.

merge: with merge.preferancestor=*, run an auction with bids from ancestors The basic idea is to do the merge planning with all the available ancestors, consider the resulting actions as "bids", make an "auction" and automatically pick the most favourable action for each file. This implements the basic functionality and will only consider "keep" and "get" actions. The heuristics for picking the best action can be tweaked later on. By default it will only pass ctx.ancestor as the single ancestor to calculateupdates. The code path for merging with a single ancestor is not changed.

log: changed implementation to use graphlog code Now that revsets work in a lazy way, log code can be changed to parse every option into a revset and then evaluate it lazily. Now expressions like "hg log -b default -b ." are converted into a revset using the same code as graphlog.

context: introduce merge.preferancestor for controlling which ancestor to pick Multiple revisions can be specified in merge.preferancestor, separated by whitespace. First match wins. This makes it possible to overrule the default of picking the common ancestor with the lowest hash value among the "best" (introduced in 3605d4e7e618). This can for instance help with some merges where the 'wrong' ancestor is used. There will thus be some overlap between this and the problems that can be solved with a future 'consensus merge'. Mercurial will show a note like note: using 40663881a6dd as ancestor of 3b08d01b0ab5 and adfe50279922 alternatively, use --config merge.preferancestor=0f6b37dbe527 when the option is available, listing all the alternative ancestors.

context: tell when .ancestor picks one of multiple common ancestors heads Show a message like note: using 0f6b37dbe527 as ancestor of adfe50279922 and cf89f02107e5 So far this is just a warning - there is nothing the user can do to select another ancestor.

hgweb: align entries in "changelog" and "revisions" pages of "spartan" style Before this patch, each log entries in "changelog" and "revisions" pages of "spartan" style are not aligned by column, because: - each log entries are separated "<table>" entries, and - there are no fixed "width" information for each "<th>"/"<td>" entries This patch aligns entries in "changelog" and "revisions" pages of "spartan" style by: - adding 'label' class to '<th>' for 'age' information, and - setting 'width' of '<th class="label">' with fixed size 'class="age"' is not used for this purpose, because it is also used to set "bold" font-weight "16em" seems to be wide enough to show date information fully, when web browser disables (or doesn't support) javascript.

hgweb: show revisions and hashes gotten from changelog in "comparison" page Before this patch, revision numbers and hash values in "comparison" page are gotten from not changelog but filelog. Such filelog information is useful only for hgweb debugging, and may confuse users. This patch shows revision numbers and hash values gotten from changelog in "comparison" page.

hgweb: show as same parents as "hg parents -r REV FILE" in pages for file Before this patch, "parents" in pages for file doesn't show as same parents as "hg parents -r REV FILE", when the specified file is not modified in the specified revision. For example, it is assumed that revision A, B and D change file "f". changelog (A) ---> (B) ---> (C) ---> (D) filelog "f" (x) ---> (y) ------------> (z) "/file/D/f" invokes "webutil.parents()" with filectx(z) gotten from changectx(D), and it returns changectx(B). This is as same result as "hg parents -r D f". In the other hand, "/file/C/f" invokes "webutil.parents()" with filectx(y') gotten from changectx(C), and it returns changectx(A), because filectx(y') is linked to changectx(B), and works like filectx(y) in some cases. In this case, revision B is hidden from users browsing file "f" in revision C. This patch shows as same parents as "hg parents -r REV FILE" in pages for file, by making "webutil.parents()" return: - "linkrev()"-ed revision only, if: - specified context instance is "filectx" (because "webutil.parents()" is invoked with changectx, too), and - (1) the revision from which filectx is gotten and (2) the one to which filectx is linked are different from each other - revision gotten from "ctx.parents()", otherwise

hgweb: make "comparison" get parent from not filelog but changelog Before this patch, "comparison" shows unexpected result, when the specified file is not modified in the specified revision, even though "diff" shows empty result. When REV doesn't change specified FILE, "diff" shows: "hg diff -c REV FILE" but "comparison" shows: "hg diff -c `hg parents -r REV FILE` FILE" In other words, the former gets parent from changelog, but the latter gets one from filelog. This may confuse users browsing (and switching "diff" and "comparison" of) files in the specified revision. This patch makes "comparison" get parent from not filelog but changelog, to show "hg diff -c REV FILE" in both "diff" and "comparison" pages.

hgweb: fix lack of "bookmarks" link in "/file" page of "paper" style This patch also fixes same problem of "coal" style, because it re-uses "filerevision.tmpl" of "paper" style. "gitweb" and "monoblue" styles don't have such problems. "spartan" style doesn't have "bookmarks" page definition itself.

hgweb: adding article link to rss feed

hgweb: adding branch names from inbranch template to rss feed

hgweb: adding branch names from inbranch template to atom feed

dirstate: report bad subdirectories as match.bad, not just a warning (BC) This seems simpler and more correct. The only test coverage for this is test-permissions.t when it says: dir: Permission denied

dirstate: improve documentation and readability of match and ignore in the walker

context: remove redundant handling of match.bad return value The 'bad' function is for reporting - it never returns anything.

match: remove last traces of unused .missing callback

match: _globre doctests

match: improve documentation - docstrings and more descriptive variable naming No real changes. pattern: 'kind:pat' as specified on the command line patterns, pats: list of patterns kind: 'path', 'glob' or 're' or ... pat: string in the corresponding 'kind' format kindpats: list of (kind, pat) tuples

largefiles: changed overridelog to work with graphlog Log for largefiles was failing for graph log since it was overriding match instead of matchandpats. [Mads Kiilerich modified this patch to address his review comments and ended up rewriting/removing most of it.]

largefiles: added test coverage for graph log [Mads Kiilerich placed this patch before the patch that makes graphlog actually work correctly for largefiles. As it is introduced here it just adds test coverage and the actual bugfix patch will show the actual change.]

cmdutil: changed _makegraphlogrevset to _makelogrevset This method will now be used to build both graphlog and log revset after this series of patches.

revlog: backout 514d32de6646 - commonancestors

localrepo: use commonancestorsheads for checking linear heritage in file commit If two revisions are linearly related, there will only be one ancestor, and commonancestors and commonancestorsheads would give the same result. commonancestorsheads is however slightly simpler, faster and more correct.

backout: use commonancestorsheads for checking linear heritage If two revisions are linearly related, there will only be one ancestor, and commonancestors and commonancestorsheads would give the same result. commonancestorsheads is however slightly simpler, faster and more correct.

revlog: introduce commonancestorsheads method Very similar to commonancestors but giving all the common ancestors heads.

parsers: remove unnecessary gca variable in index_commonancestorsheads

parsers: introduce index_commonancestorsheads This is an exact copy of index_ancestors but without the final "deepest" pruning.