Before this patch, there are three distinct "wlock" scopes in
"overriderollback":
1. "localrepository.rollback" via original "rollback" command,
2. "merge.update" for reverting standin files only, and
3. "overriderollback" specific "wlock" scope (to synchronize
largefile dirstate)
But these should be executed in the same "wlock" scope for
consistency.
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.
The phase cache file is no longer written on lock release, it is now handled by
the transaction (as changesets and obsolescence markers are).
(Hooray)
As we stop relying on the lock to write phase, repos with no existing phase
information will need to wait for a phase move or a strip to happen in order to
get the first write in the `phaseroots` file. This explain the change in
test-inherit-mode.t.
This should not have any side effects but in very obscure cases where
people interact with pre-2.1 and post-2.1 versions of Mercurial on the
same repo while having MQ patches applied but the MQ extension
disabled from time to time. A case unlikely enough to not be worth
preserving the old behavior with awful hacks.
In most case, the file creation logic will be handled by the
transaction itself. The write method has to stay around for the case
where the repository is modified outside a transaction (strip).
A new `transaction.addfilegenerator` function is added. It allows external code
to register files to be generated. See inline documentation for details.
It is important to gather all file creation logic on the transaction
as at some point we'll want to mimic the "pre-transaction-commit"
logic that we use for revlog. I'm refering to the logic that lets
hooks see the result of the transaction before it actually gets
committed.
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
