strip: make query to get new bookmark target cheaper The current query to get the new bookmark target for stripped revisions involves multiple walks up the DAG, and is really expensive, taking over 2.5 seconds on a repository with over 400,000 changesets even if just one changeset is being stripped. A slightly simplified version of the current query is max(heads(::<tostrip> - <tostrip>)) We make two observations here. 1. For any set s, max(heads(s)) == max(s). That is because revision numbers define a topological order, so that the element with the highest revision number in s will not have any children in s. 2. For any set s, max(::s - s) == max(parents(s) - s). In other words, the ancestor of s with the highest revision number not in s is a parent of one of the revs in s. Why? Because if it were an ancestor but not a parent of s, it would have a descendant that would be a parent of s. This descendant would have a higher revision number, leading to a contradiction. Combining these two observations, we rewrite the revset query as max(parents(<tostrip>) - <tostrip>) The time complexity is now linear in the number of changesets being stripped. For the above repository, the query now takes 0.1 seconds when one changeset is stripped. This speeds up operations that use repair.strip, like the rebase and strip commands.

graft: explicit current node tracking This changes graft to explicitly track the progression of commits it makes, and updates it's idea of the current node based on it's last commit, rather than from the working copy parent. This should have no effect on the value of current since we were reading the working copy parent immediately after commiting to it. The motivation for this change is that a subsequent patch will break the current node and working copy relationship. Splitting this out into a separate patch will make that one more readible.

graft: move commit info building This moves the logic for generating the commit metadata ahead of the merge operation. The only purposae of this patch is to make subsequent patches easier to read, and there should be no behavior changes.

merge with stable

merge: support calculating merge actions against non-working contexts This is not currently used. It is instead a pre-requisite to performing non-conflicting grafts in memory, which a subsequent patch will do.

merge: refactor action calculation into function This pulls the code used to calculate the changes that need to happen during merge.update() into a separate function. This is not useful on its own, but is instead preparatory to performing grafts in memory when there are no potential conflicts.

dirstate: inline more properties and methods in status hg perfstatus -u on a working directory with 170,000 files, without this change: ! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6) With this change: ! wall 1.804222 comb 1.790000 user 1.140000 sys 0.650000 (best of 6) hg perfstatus on the same directory, without this change: ! wall 1.016609 comb 1.020000 user 0.670000 sys 0.350000 (best of 10) With this change: ! wall 0.985573 comb 0.980000 user 0.650000 sys 0.330000 (best of 10)

perf: add option to perfstatus to get the status of unknown files When status needs to look at unknown files (e.g. when running hg status), it needs to use a completely different algorithm than when it doesn't (e.g. when running hg diff).

dirstate: test normalize is truthy instead of using a no-op lambda hg perfstatus -u on a working directory with 170,000 files, without this change: ! wall 1.869404 comb 1.850000 user 1.170000 sys 0.680000 (best of 6) With this change: ! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6)

merge with stable

hgweb: avoid generator exhaustion with branches

hgweb: fix iterator reuse in atom feed generation

tests: don't hardcode errno==2 for ENOENT Hurd seems to set ENOENT to 2 + 2**30, unlike everyone else.

osutil: tab damage, how i hate thee

osutil: write a C implementation of statfiles for unix This makes a big difference to performance. In a clean working directory containing 170,000 files, performance of "hg --time diff" improves from 2.38 seconds to 1.69.

merge with i18n

i18n-ja: synchronized with f94ead934067

Added signature for changeset 0c10cf819146

Added tag 2.4.1 for changeset 0c10cf819146

osutil: fix tab damage

Merge with crew

osutil: factor out creation and init of listdir_stat

dirstate: avoid use of zip on big lists In a clean working directory containing 170,000 tracked files, this improves performance of "hg --time diff" from 1.69 seconds to 1.43. This idea is due to Siddharth Agarwal.

dirstate: move file type filtering to its source This prepares us to move to a much faster statfiles implementation on Unix.

clfilter: rename `unfilteredmeth` to `unfilteredmethod` As originally intended.

clfilter: fix a false positive in the test-obsolete.t We push between two repo which once filtered looks unrelated. Weakness in the current implementation allows this push to be done without -f. But later improvement with filtering will make this push fails for unrelatedness. However we want this push to fail for including bumped changeset. So we had a smaller push --force to make them related.

clfilter: ensure that filecache on localrepo is unfiltered All filecache usage on repo is for logic that should be unfiltered. The caches should be common to all filtered instances, and computation must be done unfiltered. A dedicated storecache subclass is created for this purpose.

clfilter: add a propertycache that must be unfiltered Some of the localrepo property caches must be computed unfiltered and stored globally. Some others must see the filtered version and store data relative to the current filtering. This changeset introduces two classes `unfilteredpropertycache` and `filteredpropertycache` for this purpose. A new function `hasunfilteredcache` is introduced for unambiguous checking for cached values on unfiltered repos. A few tweaks are made to the property cache class to allow overriding the way the computed value is stored on the object. Some logic relative to _tagcaches is cleaned up in the process.

largefile: status is buggy on repoproxy, so run unfiltered For some yet-unkown reason, largefile status does not work on repoproxy. As status is not affected by filtering, we run it unfiltered. Na'Tosha Bard's view on this issue: "but, well, largefiles status is kind of an unholy piece of code"

clfilter: mq should not warn about filtered mq patches MQ warns when qstatus contains unknown nodes. With changelog filtering, a node may be unknown because it is filtered. Thus, an unfiltered repo is used for this check.

clfilter: ensure that mq performs commits on unfiltered repos

clfilter: use unfiltered repo for bookmark push logic The remote location of the bookmark may be filtered locally. This changeset ensures that bookmark movement logic has access to all the repo's content.

clfilter: `bookmark.validdest` should run on unfiltered repo The logic recently added to `bookmark.validdest` uses data about obsolete changesets to see if a bookmark destination is valid. Obsolete changesets are likely to be filtered, so we need to work on an unfiltered repository.

clfilter: unfilter some parts of the push logic Computation of common changesets during push needs to be done on the widest set possible. An unfiltered version of the repo is kept for discovery and various revset calls. The discovery code itself enforces the filtering of unserved outgoing changeset.

subrepo: add argument to "diff()" to pass "ui" of caller side (issue3712) (API) Color extension achieves colorization by overriding the class of "ui" object just before command execution. Before this patch, "diff()" of abstractsubrepo and classes derived from it has no "ui" argument, so "diff()" of hgsubrepo uses "self._repo.ui" to invoke "cmdutil.diffordiffstat()". For separation of configuration between repositories, revision 573bec4ab7ba changed the initialization source of "self._repo.ui" from "ui"(overridden) to "baseui"(plain) of parent repository. And this caused break of colorization. This patch adds "ui" argument to "diff()" of abstractsubrepo and classes derived from it to pass "ui" object of caller side.

clfilter: prevent unwanted warning about filtered parents as unknown During changectx __init__ the dirstate's parents MAY be checked. If the repo is filtered, this check will complain "working directory has unknown parents" even if the parents are perfectly known. This may happen when the repo is used for serving and the dirstate has parents that are secret, as those secret changesets will be filtered.

clfilter: strip logic should be unfiltered Strip is a "write" operation that needs to be aware of the whole repo's content before destroying changesets. Only the low level function is altered. The top level command will still process its argument filtered (if any filtering is in place).

clfilter: verify logic should be unfiltered To verify a changelog obviously needs all of it. The verify logic now ensures it works on an unfiltered repository.

clfilter: phases logic should be unfiltered Phase computations and boundary movements need to be aware of all revisions that exist in the repository to return correct results.

clfilter: unfilter computation of obsolescence related computation All obsolescence related sets need to be computed on the full unfiltered version of the repository, in particular because several of them (obsolete, extinct) are used to compute the hidden revisions. On a filtered repo, revset predicates related to these sets will be properly filtered because of revset's own pre-filtering.

clfilter: ensure changeset creation in the repo is run unfiltered This applies to both creation of new commits and application of changegroups.

clfilter: ensure changegroup generation is run unfiltered Changegroup generation logic needs to be aware of the whole repository to work properly.

clfilter: ensure `rollback` is run unfiltered Rollback logic needs to be aware of the whole repository to work properly.

clfilter: ensure cache invalidation is done on the main unfiltered repo The proxy version will not hold any cache for now. But we have to ensure all cache operations are done on the unfiltered version.

clfilter: ensure that tag logic runs unfiltered The current tag logic is not aware of filtering. We keep the status quo, ensuring that the tag cache is computed as before: without any filtering.

clfilter: ensure `branchcache` logic runs unfiltered The current branchcache construction is not aware of filtering. We keep the status quo, ensuring that the branch cache logic is computed as before: without any filtering.

clfilter: introduce an `unfilteredmethod` decorator This decorator ensure the method in run on an unfiltered version of the repository. See follow-up commit for details. This decorator is not named `unfiltered` because it would clash with the `unfilteredmethod` on `localrepo` itself.

clfilter: introduce an "unfiltered" method on localrepo This commit is part of the changelog level filtering effort. It returns the main "unfiltered" version of a repo-like object. For localrepo this means the same localrepo object. But this method will be overwritten by the filtered versions of a repository to return the core unfiltered version of the repo. Introducing this simple method first allows later commits to prepare for the use of a filtered version of a repository. A new repo method is added because a lot of users may call it. At the end of this series of commits, about 40 calls exist in core and hgext.

clfilter: remove usage of `range` and `xrange` in scmutil.revrange For changelog level filtering to take effect it need to be used for any iteration. This changeset removes usage of `range` and `xrange` that survived the first pass.

hgweb: display diff for a changeset against any parents (issue2810) During merge of branches, it is useful to compare merge results against the two parents. This change adds this support to hgweb. To specify which parent to compare to, use rev/12300:12345 where 12300 is a parent changeset number. Two links are added to changeset web page so that one can choose which parent to compare to.

branch: add missing repo argument to checknewlabel scmutil.checknewlabel takes a repo object as its first argument. When the call to this function was added in e689b0d91546, the first argument was mistakenly set to 'None'.

Merge with stable.

rebase: fix pull --rev options clashing with --rebase (issue3619) Rebase also have a plain `--rev` option used to select the rebase set (as `--base` or `--source` would). But the content of the --rev option was intended for the remote repo and is irrelevant for the local rebase operation. We expect `hg pull --rebase` to stick with the default behavior here: hg rebase --base . --dest tip(branch(.)) The `rev` option is dropped from the option passed to rebase.

dirstate: remove obsolete comment from setbranch This comment should have been removed in e689b0d91546, when the call to scmutil.checknewlabel was removed.

merge with stable

tests: fix broken fix of test-phases output

update: allow update to existing branches with invalid names (issue3710) Starting with 361ab1e2086f, users are no longer able to update a working copy to a branch named with a "bad" character (such as ':'). Prior to v2.4, it was possible to create branch names using "bad" characters, so this breaks backwards compatibility. Mercurial must allow users to update to existing branches with bad names. However, it should continue to prevent the creation of new branches with bad names. A test was added to confirm that 'hg update' works as expected. The test uses a bundled repo that was created with an earlier version of Mercurial.

commit: increase perf by building a new addlist instead of editing the old one When commiting to a repo with lots of files (>170000), manifest.py:addlistdelta takes some time because it's editing a large array many times. Changing it to build a new array instead of editing the old one saves around 0.04 seconds on a 1.64 second commit. A 2.5% gain. The gain here is pretty minor, but it was blatantly at the top of the profiler report and the fix is straight forward. I tested it by comparing the arrays produced by the new and old logic while running all of the tests.

template engine: convert generator-based iterator to list-based iterator If a template iterator is implemented with generator, the iterator is exhau= sted after we use it. This leads to undesired behavior in template. This chang= e converts a generator-based iterator to list-based iterator when template en= gine first detects a generator-based iterator. All future usages of iterator wi= ll use list instead.

command: remove phase from the list of basic command This is not a basic command. There is no reason new user should needs to know about it. Thanks to Matt Mackall for pointing this.