debugcommands: stub for debugupgraderepo command
Currently, if Mercurial introduces a new repository/store feature or
changes behavior of an existing feature, users must perform an
`hg clone` to create a new repository with hopefully the
correct/optimal settings. Unfortunately, even `hg clone` may not
give the correct results. For example, if you do a local `hg clone`,
you may get hardlinks to revlog files that inherit the old state.
If you `hg clone` from a remote or `hg clone --pull`, changegroup
application may bypass some optimization, such as converting to
generaldelta.
Optimizing a repository is harder than it seems and requires more
than a simple `hg` command invocation.
This commit starts the process of changing that. We introduce
`hg debugupgraderepo`, a command that performs an in-place upgrade
of a repository to use new, optimal features. The command is just
a stub right now. Features will be added in subsequent commits.
This commit does foreshadow some of the behavior of the new command,
notably that it doesn't do anything by default and that it takes
arguments that influence what actions it performs. These will be
explained more in subsequent commits.
--- a/mercurial/debugcommands.py Wed Jan 11 21:47:19 2017 -0500
+++ b/mercurial/debugcommands.py Thu Nov 24 16:24:09 2016 -0800
@@ -849,3 +849,28 @@
if pp[1] != nullid:
ui.write("\t%d -> %d\n" % (r.rev(pp[1]), i))
ui.write("}\n")
+
+@command('debugupgraderepo', [
+ ('o', 'optimize', [], _('extra optimization to perform'), _('NAME')),
+ ('', 'run', False, _('performs an upgrade')),
+])
+def debugupgraderepo(ui, repo, run=False, optimize=None):
+ """upgrade a repository to use different features
+
+ If no arguments are specified, the repository is evaluated for upgrade
+ and a list of problems and potential optimizations is printed.
+
+ With ``--run``, a repository upgrade is performed. Behavior of the upgrade
+ can be influenced via additional arguments. More details will be provided
+ by the command output when run without ``--run``.
+
+ During the upgrade, the repository will be locked and no writes will be
+ allowed.
+
+ At the end of the upgrade, the repository may not be readable while new
+ repository data is swapped in. This window will be as long as it takes to
+ rename some directories inside the ``.hg`` directory. On most machines, this
+ should complete almost instantaneously and the chances of a consumer being
+ unable to access the repository should be low.
+ """
+ raise error.Abort(_('not yet implemented'))
--- a/tests/test-completion.t Wed Jan 11 21:47:19 2017 -0500
+++ b/tests/test-completion.t Thu Nov 24 16:24:09 2016 -0800
@@ -109,6 +109,7 @@
debugsub
debugsuccessorssets
debugtemplate
+ debugupgraderepo
debugwalk
debugwireargs
@@ -274,6 +275,7 @@
debugsub: rev
debugsuccessorssets:
debugtemplate: rev, define
+ debugupgraderepo: optimize, run
debugwalk: include, exclude
debugwireargs: three, four, five, ssh, remotecmd, insecure
files: rev, print0, include, exclude, template, subrepos
--- a/tests/test-help.t Wed Jan 11 21:47:19 2017 -0500
+++ b/tests/test-help.t Thu Nov 24 16:24:09 2016 -0800
@@ -910,6 +910,8 @@
show set of successors for revision
debugtemplate
parse and apply a template
+ debugupgraderepo
+ upgrade a repository to use different features
debugwalk show how files match on given patterns
debugwireargs
(no help text available)
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/test-upgrade-repo.t Thu Nov 24 16:24:09 2016 -0800
@@ -0,0 +1,5 @@
+ $ hg init empty
+ $ cd empty
+ $ hg debugupgraderepo
+ abort: not yet implemented
+ [255]