We have debug commands for displaying overall revlog statistics
(debugrevlog) and for dumping a revlog index (debugindex). As part
of investigating various aspects of revlog behavior and performance,
I found it important to have an understanding of how revlog
delta chains behave in practice.
This patch implements a "debugdeltachain" command. For each revision
in a revlog, it dumps information about the delta chain. Which delta
chain it is part of, length of the delta chain, distance since base
revision, info about base revision, size of the delta chain, etc. The
generic formatting facility is used, which means we can templatize
output and get machine readable output like JSON.
This command has already uncovered some weird history in
mozilla-central I didn't know about. So I think it's valuable.
For the same reasons that we don't produce stream clone bundles with `hg
bundle`, we don't support consuming stream clone bundles with `hg
unbundle`. We introduce a complementary debug command for applying
stream clone bundles. This command is mostly to facilitate testing.
Although it may be used to manually apply stream clone bundles until a
more formal mechanism is (possibly) adopted.
Now that we have support for recognizing the streaming clone bundle
type, add a debug command for creating them.
I decided to create a new debug command instead of adding support to `hg
bundle` because stream clone bundles are not exactly used the same way
as normal bundle files and I don't want to commit to supporting them
through the official `hg bundle` command forever. A debug command,
however, can be changed without as much concern for backwards
compatibility.
As part of this, `hg bundle` will explicitly reject requests to produce
stream bundles.
This command will be required by server operators using stream clone
bundles with the clone bundles feature.
Add debugextensions command to help users debug their extension
problems. If there are no extensions command prints nothing,
otherwise it prints names of extension modules. If quiet or
verbose option is not specified it prints(after extensions name)
last version of mercurial in which given module was tested for
non internal modules or not tested with user mercurial version.
If verbose is specified it prints following information for every
extension: extension name, import source, testedwith and buglink
information.
Extensions are printed sorted by extension name.
On repositories with hundreds of thousands of files, hg
debugrebuilddirstate causes every dirstate entry to be marked lookup,
and the next hg status can take many minutes.
This adds a --minimal flag that allows us to only rebuild the parts of the
dirstate that are inconsistent. This follows two rules:
1) If a file is in the dirstate but not in the parent manifest, and it is not
marked 'add', it is busted and we should drop it.
2) If a file is not in the dirstate at all, but it is in the parent
manifest, it should be added to the dirstate and we need to mark it as
lookup.
This allows us to fix repositories where the dirstate doesn't match
the manifest much more quickly.
Tested by artificially adding bad dirstate entries (via code) for both cases
above.
Currently, there is no way to recover from a missing or corrupt fncache
file in place (a clone is required). For certain use cases such as
servers and with large repositories, an in-place repair may be
desirable. This patch adds functionality for in-place repair of the
fncache.
The `hg debugrebuildfncache` command is introduced. It ensures the
fncache is up to date by reconstructing the fncache from all seen files
encountered during a brute force traversal of the repository's entire
history.
The command will add missing entries and will prune excess ones.
Currently, the command no-ops unless the repository has the fncache
requirement. The command could later grow the ability to "upgrade" an
existing repository to be fncache enabled, if desired.
When testing this patch on a local clone of the Firefox repository, it
removed a bunch of entries. Investigation revealed that removed entries
belonged to empty (0 byte size) .i filelogs. The functionality for
pruning fncache of stripped revlogs was introduced in 93ba76bfbe8a, so
the presence of these entries likely predates this feature.
It should be possible to debug the submanifest revlogs without having
to know where they are stored (in .hg/store/meta/), so let's add a
--dir option for this purpose.
Paths into the subrepo are not yet supported.
The need to use the workingctx in the subrepo will likely be used more in the
future, with the proposed working directory revset symbol. It is also needed
with archive, if that code is to be reused to support 'extdiff -S'.
Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
as it breaks various status and diff tests.
I opted not to pass the desired revision into the subrepo method explicitly,
because the only ones that do pass an explicit revision are methods like status
and diff, which actually operate on two contexts- the subrepo state and the
explicitly passed revision.
The --prefix option is meant to be relative to the root rather than the current
working directory. This is for consistency with the rest of 'hg import' --
paths in patches are otherwise considered to be relative to the root.
In upcoming patches we'll hook this option up to the patch functions.
--exact with --prefix is currently disallowed because I can't really come up
with sensible semantics for it, especially when only part of the patch is
preserved.
Now that we have decided on the use of 'name' instead of 'label' we rename this
function accordingly.
The old method 'debuglabelcomplete' has been left as a deprecated command so
that current scripts don't break.
Mercurial backout command makes a commmit by default only when the backed out
revision is the parent of working directory and doesn't commit in any other
case.
The --commit option changes behaviour of backout to make a commit whenever
possible (i.e. there is no unresolved conflicts). This behaviour seems more
intuitive to many use (especially git users migrating to hg).
Git and svn subrepos are currently not supported. It doesn't look like git or
svn have these commands natively, so that's an area for a git or svn expert.
Like 'forget', git and svn subrepos are currently not supported. Unfortunately
the name 'remove' is already used in the subrepo classes, so we break the
convention of naming the subrepo function after the command.
See previous patch descriptions for the motivation.
The tests reflect the current state of the world -- as we add support we'll see
changes in the test output.
If the selected formatter is other than plainformatter, raw data are passed
to the formatter. In this case, it isn't necessary (and not possible) to
calculate column widths.
Field names are substituted to be the same as "log" command.
There are a few limitations:
- "binary file" message is not included in formatted output.
- no data structure for multiple files. all lines are packed to single list.
We add a ``--record-parents`` flag to debugobsolete. This can be used to record
parent information in the marker when the precursors are known locally. This
will be useful to test the "relevant markers" computation.
The `hg import` command gains a `--partial` flag. When specified, a commit will
always be created from a patch import. Any hunk that fails to apply will
create .rej file, same as what `hg qimport` would do. This change is mainly
aimed at preserving changeset metadata when applying a patch, something very
important for reviewers.
In case of failure with `--partial`, `hg import` returns 1 and the following
message is displayed:
patch applied partially
(fix the .rej files and run `hg commit --amend`)
When multiple patches are imported, we stop at the first one with failed hunks.
In the future, someone may feel brave enough to tackle a --continue flag to
import.
The --edit/-e option for the 'commit' command forces editor, even when a
commit message has been provided already by other means, such as by the -m or
-l options.
Previously, directories were added with the trailing slash and, if there was
only one completion, then another ambiguous entry was created using '.', as
follows:
$ hg rm mer<TAB>
mercurial/./ mercurial//
This was added in bc559aff745c (though, some logic existed before that) to work
around bash completion adding a space after the sole entry because we treated
directories and files the same. We no longer do that now so we remove this
unneeded code.
Tests have been updated to match this new behavior.