Before this patch, addchangegroup() would walk the changelog and compute
the set of seen files between applying changesets and applying
manifests. When cloning large repositories such as mozilla-central,
this consumed a non-trivial amount of time. On my MBP, this walk takes
~10s. On a dainty EC2 instance, this was measured to take ~125s! On the
latter machine, this delay was enough for the Mercurial server to
disconnect the client, thinking it had timed out, thus causing a clone
to abort.
This patch enables the changelog to compute the set of changed files as
new revisions are added. By doing so, we:
* avoid a potentially heavy computation between changelog and manifest
processing by spreading the computation across all changelog additions
* avoid extra reads from the changelog by operating on the data as it is
added
The downside of this is that the add revision callback does result in
extra I/O. Before, we would perform a flush (and subsequent read to
construct the full revision) when new delta chains were created. For
changelogs, this is typically every 2-4 revisions. Using the callback
guarantees there will be a flush after every added revision *and* an
open + read of the changelog to obtain the full revision in order to
read the added files. So, this increases the frequency of these
operations by the average chain length. In the future, the revlog
should be smart enough to know how to read revisions that haven't been
flushed yet, thus eliminating this extra I/O.
On my MBP, the total CPU times for an `hg unbundle` with a local
mozilla-central gzip bundle containing 251,934 changesets and 211,065
files did not have a statistically significant change with this patch,
holding steady around 360s. So, the increased revlog flushing did not
have an effect.
With this patch, there is no longer a visible pause between applying
changeset and manifest data. Before, it sure felt like Mercurial was
lethargic making this transition. Now, the transition is nearly
instantaneous, giving the impression that Mercurial is faster. Of course,
eliminating this pause means that the potential for network disconnect due
to channel inactivity during the changelog walk is eliminated as well.
And that is the impetus behind this change.
A subsequent patch will add a feature that performs iterative
computation as changesets are added from a changegroup. To facilitate
this type of processing in a generic manner, we add a mechanism for
calling a function whenever a revision is added via revlog.addgroup().
There are potential performance concerns with this callback, as using it
will flush the revlog after every revision is added.
Before this patch, crecord was crashing for large diffs
(30k lines on my laptop). This patch catches the exception raised in that case
and use the error reporting mechanism introduced in the previous patch for
notifying the user of the issue. It is not possible to add a test for that for
now as we don't yet have full blown ui tests for the curses interface.
Before this patch, we couldn't report to the user any error that occurred:
- after we enabled the curses interface but
- before the interface is set up and drawn
This patch, provides a way to set errors that happens during the initialization
of the interface and log them once the curses interface has been displayed.
If no infix action is defined, a suffix action isn't ambiguous, so it should
be taken no matter if the next token can be an operand. This is exactly the
same flow as prefix/primary handling.
This change has no effect now because all suffix tokens have infix actions.
If both actions are defined, a primary-expression action is accepted only if
the next token never starts new term. For example,
parsed as primary expression:
":" # next token 'end' has no action
"(:)" # next token ')' has no action
":+y" # next token '+' is infix operator
parsed as prefix operator:
":y" # next token 'y' is primary expression
":-y" # next token '-' is prefix operator
This is mostly the same resolution as the infix/suffix rules.
This will allow us to define both a primary expression, ":", and a prefix
operator, ":y". The ambiguity will be resolved by the next patch.
Prefix actions in elements table are adjusted as follows:
original prefix primary prefix
----------------- -------- -----------------
("group", 1, ")") -> n/a ("group", 1, ")")
("negate", 19) -> n/a ("negate", 19)
("symbol",) -> "symbol" n/a
This is the last step before supporting extdiff -S. It maintains the existing
behavior of diffing the largefile standins instead of the largefiles themselves.
Note however that the standins are not updated immediately upon modification, so
uncommitted largefile changes are ignored, as they previously were, even with
the diff command.
There are currently no users of this, but it is a necessary step before
converting extdiff to use archive. It may be useful to add an argument to
extdiff in the future and allow largefiles to be diffed, but archiving
largefiles can have significant overhead and may not be very diffable, so
archiving them by default seems wrong.
It is a mystery to me why the lfstatus attribute needs to be set on the
unfiltered repo. However if it is set on the filtered repo instead (and the
filtered repo is passed to the original command), the lfstatus attribute is
False in the overrides for archival.archive() and hgsubrepo.archive() when
invoking the archive command. This smells like the buggy status behavior (see
9fc565fa1621, which was reverted in e1574a4a2cad). Neither the status nor
summary commands have this weird behavior in their respective overrides.
If revlog file is corrupted, it can have parent pointing to invalid revision.
So we should validate it before updating nothead[], phases[], seen[], etc.
Otherwise it would cause segfault at best.
We could use "rev" instead of "maxrev" as upper bound, but I think the explicit
"maxrev" can clarify that we just want to avoid possible buffer overflow
vulnerability.
Before this patch, we were stripping temporary commits at the end of a histedit
whether it was successful or not. If we can create obs markers, we should
create them instead of stripping because it is faster and safer.
We use a variable to store whether or not we can create obsolescence markers.
It makes the patch series more readable as we are going to reuse this
values in other places in the function.
Before this patch:
- if a user was entering a commit message after having ran the curses
interface
- and then uses ctrl-z, followed by fg to put the editor in the
background/foreground
- then the curses interface would leave artefact on the screen of
the editor, making entering the commit message a difficult task
This happened because ncurses registers a signal handler for SIGTSTP and
does not restore the original signal handler after running.
More info at:
http://stackoverflow.com/questions/31440392/
curses-wrapper-messing-up-terminal-after-background-foreground-sequence/
31441709#31441709
This patch restores the original value of the signal handler after
running the curses interface and therefore fixes this issue.
It don't know how to add a test for this issue, I tested the scenario
above manually and it works correctly with the patch.
Before this patch, censored file should be exactly "a path relative to
repository root" regardless of current working directory, because "hg
censor" passes "path" to "repo.file()" directly without any
preparations.
To make various path forms available like other Mercurial commands,
this patch gets a target file path in the way of "hg parents FILE".
Getting "wctx" is relocated to reuse "wctx" for efficiency.
A fix for issue2653 with f5abbf51a76e introduced a discrepancy how default
branch should be denoted when converting with branchmap from different SCM.
E.g. for Git and Mercurial you need to use 'default' whilst for Perforce and
SVN you had to use 'None'. This changeset unifies 'default' for such purposes
whilst falling back to 'None' when no 'default' mapping specified.
Future patches will separate primary expression and prefix operator actions.
This function will be used to resolve ambiguity of them.
This is a step to remove the old-style revexpr parser. We need both ":" and
":y" operators for backward compatibility.
Before this patch, 'hg shelve -i' under non-interactive mode suggests
'use commit instead', and it obviously incorrect, because what user
wants to do isn't 'commit' but 'shelve'.
To omit incorrect 'commit' suggestion at 'hg shelve -i', this patch
specifies 'None' for 'cmdsuggest' argument of 'cmdutil.dorecord()'.
Before this patch, 'hg qrefresh -i' under non-interactive mode
suggests 'use qrefresh instead', and it obviously meaningless.
To omit meaningless 'qrefresh' suggestion at 'hg qrefresh -i', this
patch specifies 'None' for 'cmdsuggest' argument of 'cmdutil.dorecord()'.
Before this patch, 'hg qnew -i' under non-interactive mode suggests
'use qnew instead', and it obviously meaningless.
To omit meaningless 'qnew' suggestion at 'hg qnew -i', this patch adds
internal function '_qrecord()' and specifies 'cmdsuggest' for each of
'qrecord' and 'qnew' separately.
Before this patch, 'hg commit -i' under non-interactive mode suggests
'use commit instead', and it obviously meaningless.
This patch makes 'record.record'()' examine 'ui.interactive()' and
show suggestion by itself before calling 'commands.commit()'.
This allows 'commands.commit()' to specify 'None' for 'cmdsuggest'
argument of 'cmdutil.dorecord()' to omit meaningless 'commit'
suggestion at 'hg commit -i'.
Interactive committing under non-interactive mode shows command
suggestion, but sometimes it is meaningless.
command suggestion usability
------------ ---------- -----------
record commit
commit -i commit meaningless
qrecord qnew
qnew -i qnew meaningless
qrefersh -i qrefresh meaningless
shelve -i commit incorrect
------------ ---------- -----------
This patch allows callers of 'cmdutil.dorecord()' to omit meaningless
suggestion by passing None or so for 'cmdsuggest' argument of it.
This is a preparation for subsequent patches, which fix each
suggestion issues above.
Just to be consistent with log and shortlog links, graph links should have a
revision context too. And the same goes for the graph page, where it's log and
shortlog links that should have context.
This script scans files for lines that look like either ui.config
usage or config variable documentation. It then ensures:
- ui.config calls for each option agree on types and defaults
- every option appears to be mentioned in documentation
It doesn't complain about devel/experimental options and allows
marking options that are not intended to be public.
Since we haven't been able to come up with a good scheme for
documenting config options at point of use, this will help close the
loop of making sure all options that should be documented are.
