parsers: a C implementation of the new ancestors algorithm The performance of both the old and new Python ancestor algorithms depends on the number of revs they need to traverse. Although the new algorithm performs far better than the old when revs are numerically and topologically close, both algorithms become slow under other circumstances, taking up to 1.8 seconds to give answers in a Linux kernel repo. This C implementation of the new algorithm is a fairly straightforward transliteration. The only corner case of interest is that it raises an OverflowError if the number of GCA candidates found during the first pass is greater than 24, to avoid the dual perils of fixnum overflow and trying to allocate too much memory. (If this exception is raised, the Python implementation is used instead.) Performance numbers are good: in a Linux kernel repo, time for "hg debugancestors" on two distant revs (24bf01de7537 and c2a8808f5943) is as follows: Old Python: 0.36 sec New Python: 0.42 sec New C: 0.02 sec For a case where the new algorithm should perform well: Old Python: 1.84 sec New Python: 0.07 sec New C: measures as zero when using --time (This commit includes a paranoid cross-check to ensure that the Python and C implementations give identical answers. The above performance numbers were measured with that check disabled.)

revlog: choose a consistent ancestor when there's a tie Previously, we chose a rev based on numeric ordering, which could cause "the same merge" in topologically identical but numerically different repos to choose different merge bases. We now choose the lexically least node; this is stable across different revlog orderings.

ancestor: a new algorithm that is faster for nodes near tip Instead of walking all the way to the root of the DAG, we generate a set of candidate GCA revs, then figure out which ones will win the race to the root (usually without needing to traverse all the way to the root). In the common case of nodes that are close to each other in both revision number and topology, this is usually a big win: it makes "hg --time debugancestors" up to 9 times faster than the more general ancestor function when measured on heads of the linux-2.6 hg repo. Victory is not assured, however. The older function can still win by a large margin if one node is much closer to the root than the other, or by a much smaller amount if one is an ancestor of the other. For now, we've also got a small paranoid harness function that calls both ancestor functions on every input and ensures that they give equivalent answers. Even without the checker function, the old ancestor function needs to stay alive for the time being, as its generality is used by context.filectx.merge.

update: allow dirty update to foreground (successors) Update to "foreground" are no longer seen as cross branch update. "Foreground" are descendants or successors (or successors of descendants (or descendant of successors (etc))). This allows to update with uncommited changes that get automatically merged. This changeset is a small step forward. We want to allow dirty update to "background" (precursors) and takes obsolescence in account when finding the default update destination. But those requires deeper changes and will comes in later changesets.

obsolete: extract foreground computation from bookmark.validdest This foreground logic will be reused by update logic.

destroyed: invalidate phraserevs cache in all case (issue3858) When revisions are destroyed, the `phaserevs` cache becomes invalid in most case. This cache hold a `{rev => phase}` mapping and revision number most likely changed. Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets destruction. When some roots are filtered the `phaserevs` cache is invalidated. But not if none root where destroyed. We now invalidate the cache in all case filtered root or not. This bug was a bit tricky to reproduce as in most case we either: * rebase a set a draft changeset including root (phaserev invalidated) * strip tip-most changesets (no re-numbering of revision) Note that the invalidation of `phaserevs` are not strictly needed when only tip-most part of the history have been destroyed. But I do not expect the overhead to be significant.

largefiles: deprecate --all-largefiles for pull The same can be achieved with --lfrev pulled() and we shouldn't advertise unnecessary command line options.

largefiles: implement pull --all-largefiles as a special case of --lfrev

largefiles: drop --cache-largefiles again This goes a step further than d69585a5c5c0 and backs out the unreleased --cache-largefiles option. The same can be achieved with --lfrev heads(pulled()) and we shouldn't introduce unnecessary command line options.

largefiles: introduce pulled() revset expression for use in --lfrev This provides a general way to do what already can be done with --all-largefiles and --cache-largefiles.

largefiles: introduce pull --lfrev option The revset will be evaluated after the changesets has been pulled, and missing largefiles from matching revisions will be pulled to the local caches. This in combination with revsets will make it possible to specify different strategies for pulling largefiles. The revset expressions used for this option might be quite complex and will probably be most useful from scripts or an alias ... but less complicated than configuring hooks.

largefiles: refactor overridepull internals

largefiles: introduce lfpull command for pulling missing largefiles

largefiles: update help Some clarifications, and some clean-up after --cache-largefiles was introduced.

largefiles: fix cat of non-largefiles from subdirectory We were calling back to the original commands.cat from inside the walk loop that handled and filtered out largefiles. That did however happen with file paths relative to repo root and the original cat would fail when it applied its own walk and match on top of that. Instead we now duplicate and modify the code from commands.cat and patch it to handle both normal and largefiles. A change in test output shows that this also makes the exit code with largefiles consistent with the normal one in the case where one of several specified files are missing. This also fixes the combination of --output and largefiles.

largefiles: don't store whole file in memory for 'cat'

mergetools: rename 'base' to 'merged' in meld This makes it clear which panel is the target of the merge operation.

mergetools: avoid losing the merged version with meld Add -o $output. When using Meld as intended (merge from left and right into the center panel), the merged version is written to the wrong file without this option ($base, a temporary file, which is ignored by Mercurial). Add meld.check=changed as a secondary safety net.

templatekw: add default styles for hybrid types (issue3887) This allows elements like file_copies to be printed as 'name (source)' when used with join.

largefiles: improve repo wrapping detection Before this patch, repo wrapping detection in "reposetup()" of largefiles can detect only limited repo wrapping: replacing target functions by another one named as "wrap". So, it can't detect repo wrapping even in recommended style: replacing "__class__" of repo by derived class. This patch can detect repo wrapping in both styles below: - replacing "__class__" of repo by derived class (recommended style): class derived(repo.__class__): def push(self, *args, **kwargs): return super(derived, self).push(*args, **kwargs) repo.__class__ = derived - replacing function of repo by another one (not recommended style): orgpush = repo.push def push(*args, **kwargs): return orgpush(*args, **kwargs) repo.push = push

hgweb: respond HTTP_NOT_FOUND when an archive request does not match any files

archive: raise error.Abort if the file pattern matches no files Note that we could raise this exception even if no pattern were specified, but the revision contained no files. However this should not happen in practice since in that case commands.py/archive would exit earlier with an "no working directory: please specify a revision" error message instead.

ui: add 'force' parameter to traceback() to override the current print setting This will allow a current traceback.print_exc() call in dispatch to be replaced with ui.traceback() even if --traceback was not given on the command line.

ui: add support for fully printing chained exception stacks in ui.traceback() Currently, only SubrepoAbort has a cause chained to it.

subrepo: chain the original exception to SubrepoAbort The tracebacks in subrepos are truncated at the point where the original exception is caught and SubrepoAbort is raised in its place since 9e3910db4e78. That hides the most relevant subrepo methods when an error occurs. Python 2.x doesn't support chaining exceptions, so it is manually done here for manual printing later.

debugrebuildstate: rename to debugrebuilddirstate There is a lot of state, but this command is for rebuilding the dirstate.

debugstate: rename to debugdirstate There is a lot of state, but this command is for debugging the dirstate.

debugrebuildstate: clarify that rev can't be specified without -r -r has a default value of '' in the command line. The function default value of 'tip' is thus never used and any attempt at specifying revisions without -r will fail. It seems like then intended behavior was that 'hg debugrebuildstate' without any parameters should set the parents to tip. That would be very confusing now when the command primarily is used to recover from incorrect stat info. It is apparently undocumented that '' is the same as '.' ... unless it is passed in a place where revsets are used.

check-code: check txt files for trailing whitespace

check-code: catch trailing space in comments

spelling: fix typos and spelling errors

wireproto: clarify cryptic 'remote: unsynced changes' error message on push The message was not very much to the point and did not in any way help an ordinary user. 'repository changed while preparing/uploading bundle - please try again' is more correct, gives the user some understanding of what is going on, and tells how to 'recover' from the situation. The 'bundle' aspect could be seen as an implementation detail that shouldn't be mentioned, but I think it helps giving an exact error message. The message could still leave the user wondering why Mercurial doesn't lock the repo and how unsafe it thus is. Explaining that is however too much detail.