test-gendoc complained:
% extracting documentation from ru
checking for parse errors
+ gendoc-ru.txt:5686: (WARNING/2) Field list ends without a blank
line; unexpected unindent.
+ gendoc-ru.txt:8327: (WARNING/2) Definition list ends without a
blank line; unexpected unindent.
Buildbot complained:
$ python check-translation.py *.po
+ ru.po:9576:fatal(promptchoice): number of choices differs between
msgid and msgstr
+ [1]
Prompt text was obviously wrong.. because it didn't include a prompt.
When reversing a status, trading "added" and "removed" make sense.
Reversing "deleted" and "unknown" does not. We stop doing it.
The reversing is documented in place for the poor soul not even able to remember
the index of all status elements by heart.
By the magic of code movement, we ended up dropping unknown and ignored
information when comparing the working directory with a non-parent revision.
Let's stop doing it and add a test.
Changeset 83ad0e76acc0 introduced a test to validate that file were not reported
twice when both unknown and removed. This behavior change was introduced by
64d05ea3a10f alongside a bug that dropped ignored and unknown completely
(issue4321). As we are going to fix the bug, we need a proper implementation of
the behavior tested in 83ad0e76acc0.
This is a quick fix for some consoles on windows (consoles that are not mingw
based) so that the debugcolor command doesn't throw a KeyError when effects
aren't supported (e.g. italic).
dirstate.normal is the method that marks files as unchanged/normal.
Rev 03dc7365e275 started caching dirstate.normal in order to improve
performance. However, there was an error in the patch: taking the wlock, under
some conditions depending on platform, can cause a new dirstate object to be
created. Caching dirstate.normal before calling wlock would then cause the
fixup calls below to be on the old dirstate object, effectively disappearing
into the ether.
On Unix and Unix-like OSes, the condition under which we create a new dirstate
object is 'the dirstate file has been modified since the last time we opened
it'. This happens pretty rarely, so the object is usually the same -- there's
little impact.
On Windows, the condition is 'always'. This means files in the lookup state are
never marked normal, so the bug has a serious performance impact since all the
files in the lookup state are re-read every time hg status is run.
Old behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic topic (!) - cmd
showconfig cmd topic (!) - cmd
rebase cmd cmd ext cmd
New behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic cmd - cmd
showconfig cmd cmd - cmd
rebase cmd cmd ext cmd
This patch makes the warning message for "patch --partial"
translatable: this message was introduced by a0ab8b02be69, and there is
no reason to prevent this from being translatable.
This patch fixes argument mismatch at formatting the abort message,
introduced by dcf325a55d85: the last '%s' doesn't have corresponded
argument.
This patch uses "unexpected size" in the abort message, to distinguish
the reason of failure from "unexpected type" failure checked in the
prior code path below:
if info[1] != type:
raise util.Abort(_('cannot read %r object at %s') % (type, rev))
When using an editor path with spaces and options, you can set 'ui.editor'
to '"/path to your/editor" -opt' and it works fine but 'hg debuginstall'
is complaining about it because it simply splits the editor and
tests presence of '"/path'.
Now correctly parse 'ui.editor' string by handling quoted path.
This patch changes help text for "--edit" option of commands below:
- fetch
- qnew
- qrefresh
- qfold
- commit
- tag
This unification reduces translation cost, too.
This patch chooses not "further edit commit message already specified"
(of "hg commit") but "invoke editor on commit messages" as unified
help text for "--edit" option, because the latter is much older than
the former.
This patch changes help text for "--message" option of commands below
for unification.
- sign (of gpg)
- tag
This unification reduces translation cost, too.
This patch doesn't change the description for "--message" of "hg
rebase" below, because this should contain "collapse" word to explain
its purpose (only for "--collapse") clearly.
use text as collapse commit message
We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.
In Mercurial 3.0, "hg status" can list the same file twice if it was removed
but still exists in working directory, i.e. removed by "hg forget":
$ hg status --rev 0 removed
R removed
? removed
But since 64d05ea3a10f, untracked state, "?", is no longer displayed in this
example.
I think the new behavior is correct since a file should have single state, but
if it is a bug, this patch should be dropped.
When a bundle2 parts generator returns a non callable value, it should not be
used as a reply handler. The changegroup part generator is already having this
case of behavior when there is no changegroup to push. This changeset prevent a
crash for user of the experimentable bundle2 feature.
With this change resolve and revert produce consistent output when run with no
arguments:
$ hg resolve
abort: no files or directories specified
(use --all to remerge all files)
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
f5a63a5506d2 regressed performance of baseset.__sub__ by introducing
a lazyset. This patch restores that lost performance by eagerly
evaluating baseset.__sub__ if the other set is a baseset.
revsetbenchmark.py results impacted by this change:
revset #6: roots(0::tip)
0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4)
1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100)
revset #23: roots((0:tip)::)
0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4)
1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61)
On the author's machine, this slowdown manifested during evaluation of
'roots(%ln::)' in phases.retractboundary after unbundling the Firefox
repository. Using `time hg unbundle firefox.hg` as a benchmark:
Before: 8:00
After: 4:28
Delta: -3:32
For reference, the subset and cs baseset instances impacted by this
change were of lengths 193634 and 193627, respectively.
Explicit test coverage of roots(%ln::), while similar to the existing
roots(0::tip) benchmark, has been added.
Setting substate to None was an oversight in 5b3c9729fe09 and this patch
corrects it by setting substate to an empty dictionary which matches what
subrepo code expects.
Before this patch, largefiles gotten from revisions other than the
parent of the working directory at "hg revert" become "clean"
unexpectedly in steps below:
1. "repo.status()" is invoked (for status check before reverting)
1-1 "dirstate" entry for standinfile SF is "normal"-ed
(1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)
2. "cmdutil.revert()" is invoked
2-1 standinfile SF is updated in the working directory
2-2 "dirstate" entry for SF is NOT updated
3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
3-1 largefile LF (for SF) is updated in the working directory
3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
3-3 "lfdirstate" entry for LF is "normal"-ed
3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file (by 3-3)
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 3-3 and 3-4) as "clean".
When largefiles are reverted, they should be "normallookup"-ed
forcibly.
This patch uses "normallookup" on "lfdirstate" while reverting, by
passing "True" to newly added argument "normallookup".
Forcible "normallookup"-ing is not so expensive, because list of
target largefiles is explicitly specified in this case.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)