47985606a0ae (run-tests: check if stream is a tty before using color,
2017-07-18) made the check redundant but forgot to remove it.
Differential Revision: https://phab.mercurial-scm.org/D116
At first I updated the color field of the 'options' object (from the
CLI parser), but then I decided to put it directly on the test case
object itself to avoid mutating the shared object (even though all
tests would have the same value).
Differential Revision: https://phab.mercurial-scm.org/D114
Previously, we trust Differential Revision in commit message blindly. This
patch adds sanity check so a host name change will be detected and the
commit message will be ignored.
Differential Revision: https://phab.mercurial-scm.org/D35
Previous implementation (ccf66c9bf5af) checked only if sys.stderr was a tty
which was less general. Also makes sure that colors is never used if pygments is
not available, irrespective of --color flag value.
This makes it much clearer because each test case can have exactly the
graph it wants (no extra cruft just because other tests want it).
Differential Revision: https://phab.mercurial-scm.org/D94
Consider a graph like this:
D
|\
B C
|/
A
drawdag will add a file called A in commit A, file B in B, file C in
C. That's fine and expected. In merge commits like D, I would expect
the files and their contents to be taken from the parent commits, so
commit D in this example would have files A, B, and C. However,
drawdag will instead add the file D compared to the first
parent. Depending on whether B or C got a smaller nodeid, the contents
of D would be {A, B, D} or {A, C, D}. This patch changes it to to be
{A, B, C}.
Differential Revision: https://phab.mercurial-scm.org/D92
Without this, multiple spaces or tabs in the commit message aren't
preserved and things like tables don't align properly.
As part of adding the CSS rule, we had to cuddle the content
with the <div> to not introduce leading and trailing whitespace.
The "addbreaks" filter was also removed because it would insert
an additional newline, effectively double spacing content.
Differential Revision: https://phab.mercurial-scm.org/D113
The presence of a sparse checkout can confuse legacy clients or
clients without sparse enabled for reasons that should be obvious.
This commit introduces a new repository requirement that tracks
whether sparse is enabled. The requirement is added when a sparse
config is activated and removed when the sparse config is reset.
The localrepository constructor has been taught to not open repos
with this requirement unless the sparse feature is enabled. It yields
a more actionable error message than what you would get if the
lockout were handled strictly at the requirements verification phase.
Old clients that aren't sparse aware will see the generic
"repository requires features unknown to this Mercurial" error,
however.
The new requirement has "exp" in its name to reflect the
experimental nature of sparse. There's a chance that the eventual
non-experimental feature won't change significantly and we could
have squatted on the "sparse" requirement without ill effect. If
that happens, we can teach new clients to still recognize the old
name. But I suspect we'll sneak in some BC and we'll want a new
requirement to convey new meaning.
Differential Revision: https://phab.mercurial-scm.org/D110
In 3 functions we were writing the sparse config and updating the
working directory. In two of them we had a transaction-like process
for restoring the sparse config in case of wdir update fail.
Because the pattern is common, we've already made mistakes, and the
complexity will increase in the near future, let's consolidate the
code into a reusable function.
As part of this refactor, we end up reading the "sparse" file twice
when updating it. This is a bit sub-optimal. But I don't think it
is worth the code complexity to pass around the variables to avoid
the redundancy.
Differential Revision: https://phab.mercurial-scm.org/D109
The repo instance is currently only used to provide a changeset
lookup function as part of parsing revsets. I /think/ this allows
node fragments to resolve. I'm not sure why we wouldn't want this
to always "just work" if parsing a revset string.
Plus, an upcoming commit will introduce a new consumer that needs a
handle on the repo. So passing it more often will make that code
work more.
Passing a repo instance in all callers of revset.match* results in
a bunch of test changes. Notably, branch and tags caches get
populated as part of evaluating revsets. I'm not sure if this is
desirable. So this patch takes the conservative approach and only
passes the repo if we're passing a ui instance.
Differential Revision: https://phab.mercurial-scm.org/D97
e80041832e introduced support to color the output of tests but used pygments
without checking whether it's installed or not. That breaks test-run-tests.t for
machines which don't have pygments installed. This patch conditionalize the
color test in test-run-tests.t and also add a check to make sure pygments is
installed before using that.
Previously, [include] was implicit and pattern lines before a
[section] were added to includes.
Because the format may change in the future and explicit behavior,
well, more explicit, this commit changes the config parser to
reject pattern lines that don't occur in a [section].
Differential Revision: https://phab.mercurial-scm.org/D96
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).
The 4.2 release introduces a regression regarding the behavior of rebase with
some hook failures. We add the tests from the bug report from Henrik Stuart to
our test base to prevent further regression on this.
Having a single transaction for rebase means the whole transaction gets rolled back
on error. To work around this a small hack has been added to detect merge
conflict and commit the work done so far before exiting. This hack works because
there is nothing transaction related going on during the merge phase.
However, if a hook blocks the rebase to create a changeset, it is too late to commit the
work done in the transaction before the problematic changeset was created. This
leads to the whole rebase so far being rolled back. Losing merge resolution and
other work in the process. (note: rebase state will be fully lost too).
Since issue5610 is a pretty serious regression and the next stable release is a
couple day away, we are taking the backout route until we can figure out
something better to do.
In the process of fixing issue5610 in 4.2.2, we are trying to backout
507f16f4aa51. This changeset is making changes that depend on 507f16f4aa51,
so we need to back it out first.
Since issue5610 is pretty serious regression and the next stable release is a
couple of days away, we are taking the backout route until we can figure out
something better to do.
Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
This adds an experimental flag -t/--terse which will terse the output. The terse flag
will respect other flags which filters the output. The flag takes a string
whose value can be a subsequence of "marduic" (the order does not matter here.)
Ignored files are not considered while tersing unless -i flag is passed or 'i'
is there is the terse flag value.
The flag is experimental for testing as there may be cases which will produce
strange results with the flag. We can set the terse on by default by simply
passing 'u' to the cmdutil.tersestatus().
This patch also adds a test file with tests covering the new feature.
This patch adds check to make the arguments are passed as KEY=VALUE and no key
which is used internally is passed.
This patch also adds test for the extension.
Experimental because given the possible complexity, it may be worth figuring out
how to load this from a file, similar to the style files for the log command,
instead of trying to stuff it on the command line.
There are no visible changes here.
I'm starting to wonder if adding the '+' to the 'node' line instead of a
separate key line in a4d42f6edc09 was the right thing to do. The '{node}'
keyword never includes '+' elsewhere, and the way setup.py works, it would
truncate it anyway. Additionally, the file is missing '{p2node}' when 'wdir()'
merges are archived. I thought about adding an 'identify' line that would
correspond to `hg id -n`. But the other nodes are the full 40 characters, and
the output most useful for versioning is the short form. All of this cries out
for customization via templating. (Although maybe having the short identify
line by default is still a good idea.)
Now that we records "all" changes happening in a transaction (in tr.changes)
we will be able to provide better report on various changes (phases turned
public, changeset obsoleted, branch merged or created, etc..)
This is far too late in the cycle to play with this, but having this existing
method called more widely will help extensions to play around with various
options during the 4.4 cycle.
Instead of calling registersummarycallback only for transactions we want, we
always call it and use the transaction name to decide when to report (eg: we
do not want `hg amend` to report new obsoleted changesets). Filtering on
transaction name does not seems great, but seems good enough for the moment.
We can change the API during the next cycle.
The previous manual call during unbundling of the bundle2 "obsmarkers" part is
no longer necessary and has been dropped.
The 'self' argument is already taken care of by the 'super(...)' call. Instead
we were passing the repository instance as the 'desc' value.
This got discovered by breaking the next changeset.
Share extension now also share caches reads and writes. Not sharing caches
results in costly caches recomputations which can takes up to minutes when
using shares on large repositories.
There are a couple of file in the '.hg/cache/' that depends of the current
visibility. Visibility can be affected by the working copy location, something
which is specific to each share. We ignores them for this series because they:
* are the minority,
* already have a good fallback to other precomputed caches,
* are only affected when people use the experimental evolution feature.
