revlog: add an experimental option to mitigated delta issues (issue5480) The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).

tests: use system hg only if changelog or dirstate can't be read The bundled hg should work flawlessly in most cases. Make it depend on the external installation only if necessary since we can't control the whole environment. This patch doesn't implement the "exit 80" idea proposed by Jun. I don't want to keep the capability checking sync with the actual tests.

tests: restore workaround of obsolete warning from 3c9066ed557c It's simple and works well unless you are using third-party extensions that changes the store format.

tests: alias syshg and syshgenv so they can be switched conditionally

tests: actually restore the original environment before running syshg Since os.environ may be overridden in run-tests.py, several important variables such as PATH weren't restored. I don't like the idea of using the system hg *by default* because the executable and the configs are out of our control. But I don't mind as long as the tests pass.

Added signature for changeset 26c49ed51a69

Added tag 4.2.2 for changeset 26c49ed51a69

phabricator: add phabread command to read patches This patch adds a `phabread` command generating plain-text patches from Phabricator, suitable for `hg import`. It respects `hg:meta` so user and date information might be preserved. And it removes `Summary:` field name which makes the commit message a bit tidier. To support stacked diffs, a `--stack` flag was added to read dependent patches recursively.

phabricator: add phabsend command to send a stack The `phabsend` command is intended to provide `hg email`-like experience - sending a stack, setup dependency information and do not amend existing changesets. It uses differential.createrawdiff and differential.revision.edit Conduit API to create or update a Differential Revision. Local tags like `D123` are written indicating certain changesets were sent to Phabricator. The `phabsend` command will use obsstore and tags information to decide whether to update or create Differential Revisions.

phabricator: add a contrib script The default Phabricator client arcanist is not friendly to send a stack of changesets. It works better when a feature branch is reviewed as a single review unit. However, we want multiple revisions per feature branch. To be able to have an `hg email`-like UX to send and receive a stack of commits easily, it seems we have to re-invent things. This patch adds `phabricator.py` speaking Conduit API [1] in `contrib` as the first step. This may also be an option for people who don't want to run PHP. Config could be done in `hgrc` (instead of `arcrc` or `arcconfig`): [phabricator] # API token. Get it from https://phab.mercurial-scm.org/conduit/login/ token = cli-xxxxxxxxxxxxxxxxxxxxxxxxxxxx url = https://phab.mercurial-scm.org/ # callsign is used by the next patch callsign = HG This patch only adds a single command: `debugcallconduit` to keep the patch size small. To test it, having the above config, and run: $ hg debugcallconduit diffusion.repository.search <<EOF > {"constraints": {"callsigns": ["HG"]}} > EOF The result will be printed in prettified JSON format. [1]: Conduit APIs are listed at https://phab.mercurial-scm.org/conduit/

show: implement "stack" view People often want to know what they are working on *now*. As part of this, they also commonly want to know how that work is related to other changesets in the repo so they can perform common actions like rebase, histedit, and merge. `hg show work` made headway into this space. However, it is geared towards a complete repo view as opposed to just the current line of work. If you have a lot of in-flight work or the repo has many heads, the output can be overwhelming. The closest thing Mercurial has to "show me the current thing I'm working on" that doesn't require custom revsets is `hg qseries`. And this requires MQ, which completely changes workflows and repository behavior and has horrible performance on large repos. But as sub-optimal as MQ is, it does some things right, such as expose a model of the repo that is easy for people to reason about. This simplicity is why I think a lot of people prefer to use MQ, despite its shortcomings. One common development workflow is to author a series of linear changesets, using bookmarks, branches, anonymous heads, or even topics (3rd party extension). I'll call this a "stack." You periodically rewrite history in place (using `hg histedit`) and reparent the stack against newer changesets (using `hg rebase`). This workflow can be difficult because there is no obvious way to quickly see the current "stack" nor its relation to other changesets. Figuring out arguments to `hg rebase` can be difficult and may require highlighting and pasting multiple changeset nodes to construct a command. The goal of this commit is to make stack based workflows simpler by exposing a view of the current stack and its relationship to other releant changesets, notably the parent of the base changeset in the stack and newer heads that the stack could be rebased or merged into. Introduced is the `hg show stack` view. Essentially, it finds all mutable changesets from the working directory revision in both directions, stopping at a merge or branch point. This limits the revisions to a DAG linear range. The stack is rendered as a concise list of changesets. Alongside the stack is a visualization of the DAG, similar to `hg log -G`. Newer public heads from the branch point of the stack are rendered above the stack. The presence of these heads helps people understand the DAG model and the relationship between the stack and changes made since the branch point of that stack. If the "rebase" command is available, a `hg rebase` command is printed for each head so a user can perform a simple copy and paste to perform a rebase. This view is alpha quality. There are tons of TODOs documented inline. But I think it is good enough for a first iteration.

tests: demonstrate inconsistencies with dirty state in various commands Not only is the output of these commands inconsistent with respect to each other when a file is deleted, they are internally inconsistent depending upon whether the deleted file is in the top level repo or a subrepo. It seemed easier to show the problems, rather than describe them. The original goal was to fix the summary command with respect to deleted files. I haven't fixed any of the other issues yet, in case anybody believes the current subrepo behavior is correct. I think a natural understanding of clean/dirty is that they are two opposite values of a single binary repo state. If `hg update --clean -r .` changes a file, then naturally that repo was dirty, and `hg update --check` should have blocked it. Deleted files are special, in that they don't block a commit. But they make the filesystem content not the same as a clean checkout.

check-config: syntax to allow inconsistent config values The ignore regular expression has been updated to detect "inconsistent config." If present, we track which configs have that set and we suppress the conflicting defaults error for those options. I also added named groups to the regexp to aid readability. A comment was added to profiling.py to make a desired inconsistent value error go away.

configitems: register the 'badserver.closebeforeaccept' config

configitems: register the 'badserver.closeaftersendbytes' config

configitems: register the 'badserver.closeafterrecvbytes' config

configitems: register the 'badserver.closeafteraccept' config

configitems: register the 'blackbox.logsource' config

configitems: register the 'blackbox.dirty' config

configitems: register the 'automv.similarity' config Default value has been ported.

acl: use configlist to retrieve the source config This is what the previous code was about.

configitems: register the 'acl.sources' config The existing default value is now formally declared. It seems like the whole config should be a list, but this is an adventure for the next changesets.

configitems: register the 'acl.config' config

config: register the 'devel.legacy.exchange' config