[PATCH 1 of 2 V2] upgrade: add '-' in optimization name
Boris Feld
boris.feld at octobus.net
Mon Dec 31 15:19:23 UTC 2018
# HG changeset patch
# User Boris Feld <boris.feld at octobus.net>
# Date 1531443930 -7200
# Fri Jul 13 03:05:30 2018 +0200
# Node ID 0713443cf6e40b7e6409cdd898d5ba22b4d02e48
# Parent 5c68b617ba2463eb6f1372a24b139a376c6bf6bd
# EXP-Topic upgrade-test
# Available At https://bitbucket.org/octobus/mercurial-devel/
# hg pull https://bitbucket.org/octobus/mercurial-devel/ -r 0713443cf6e4
upgrade: add '-' in optimization name
The older name `redeltaall` was hard to type and read. The newer form should
be more user-friendly.
We keep backward compatibility with the old form (at least for a while).
Having to use different form depending on the version is very impractical and
error prone.
diff --git a/mercurial/upgrade.py b/mercurial/upgrade.py
--- a/mercurial/upgrade.py
+++ b/mercurial/upgrade.py
@@ -348,6 +348,19 @@ def finddeficiencies(repo):
return deficiencies
+# search without '-' to support older form on newer client.
+#
+# We don't enforce backward compatibility for debug command so this
+# might eventually be dropped. However, having to use two different
+# forms in script when comparing result is anoying enough to add
+# backward compatibility for a while.
+legacy_opts_map = {
+ 'redeltaparent': 're-delta-parent',
+ 'redeltamultibase': 're-delta-multibase',
+ 'redeltaall': 're-delta-all',
+ 'redeltafulladd': 're-delta-fulladd',
+}
+
def findoptimizations(repo):
"""Determine optimisation that could be used during upgrade"""
# These are unconditionally added. There is logic later that figures out
@@ -355,7 +368,7 @@ def findoptimizations(repo):
optimizations = []
optimizations.append(improvement(
- name='redeltaparent',
+ name='re-delta-parent',
type=optimisation,
description=_('deltas within internal storage will be recalculated to '
'choose an optimal base revision where this was not '
@@ -368,7 +381,7 @@ def findoptimizations(repo):
'base revision if needed')))
optimizations.append(improvement(
- name='redeltamultibase',
+ name='re-delta-multibase',
type=optimisation,
description=_('deltas within internal storage will be recalculated '
'against multiple base revision and the smallest '
@@ -385,7 +398,7 @@ def findoptimizations(repo):
'significantly')))
optimizations.append(improvement(
- name='redeltaall',
+ name='re-delta-all',
type=optimisation,
description=_('deltas within internal storage will always be '
'recalculated without reusing prior deltas; this will '
@@ -396,12 +409,12 @@ def findoptimizations(repo):
'execution time')))
optimizations.append(improvement(
- name='redeltafulladd',
+ name='re-delta-fulladd',
type=optimisation,
description=_('every revision will be re-added as if it was new '
'content. It will go through the full storage '
'mechanism giving extensions a chance to process it '
- '(eg. lfs). This is similar to "redeltaall" but even '
+ '(eg. lfs). This is similar to "re-delta-all" but even '
'slower since more logic is involved.'),
upgrademessage=_('each revision will be added as new content to the '
'internal storage; this will likely drastically slow '
@@ -654,20 +667,20 @@ def _upgraderepo(ui, srcrepo, dstrepo, r
ui.write(_('(it is safe to interrupt this process any time before '
'data migration completes)\n'))
- if 'redeltaall' in actions:
+ if 're-delta-all' in actions:
deltareuse = revlog.revlog.DELTAREUSENEVER
- elif 'redeltaparent' in actions:
+ elif 're-delta-parent' in actions:
deltareuse = revlog.revlog.DELTAREUSESAMEREVS
- elif 'redeltamultibase' in actions:
+ elif 're-delta-multibase' in actions:
deltareuse = revlog.revlog.DELTAREUSESAMEREVS
- elif 'redeltafulladd' in actions:
+ elif 're-delta-fulladd' in actions:
deltareuse = revlog.revlog.DELTAREUSEFULLADD
else:
deltareuse = revlog.revlog.DELTAREUSEALWAYS
with dstrepo.transaction('upgrade') as tr:
_copyrevlogs(ui, srcrepo, dstrepo, tr, deltareuse,
- 'redeltamultibase' in actions)
+ 're-delta-multibase' in actions)
# Now copy other files in the store directory.
# The sorted() makes execution deterministic.
@@ -731,7 +744,9 @@ def _upgraderepo(ui, srcrepo, dstrepo, r
def upgraderepo(ui, repo, run=False, optimize=None):
"""Upgrade a repository in place."""
- optimize = set(optimize or [])
+ if optimize is None:
+ optimize = []
+ optimize = set(legacy_opts_map.get(o, o) for o in optimize)
repo = repo.unfiltered()
# Ensure the repository can be upgraded.
diff --git a/tests/test-upgrade-repo.t b/tests/test-upgrade-repo.t
--- a/tests/test-upgrade-repo.t
+++ b/tests/test-upgrade-repo.t
@@ -131,17 +131,17 @@ An upgrade of a repository created with
additional optimizations are available by specifying "--optimize <name>":
- redeltaparent
+ re-delta-parent
deltas within internal storage will be recalculated to choose an optimal base revision where this was not already done; the size of the repository may shrink and various operations may become faster; the first time this optimization is performed could slow down upgrade execution considerably; subsequent invocations should not run noticeably slower
- redeltamultibase
+ re-delta-multibase
deltas within internal storage will be recalculated against multiple base revision and the smallest difference will be used; the size of the repository may shrink significantly when there are many merges; this optimization will slow down execution in proportion to the number of merges in the repository and the amount of files in the repository; this slow down should not be significant unless there are tens of thousands of files and thousands of merges
- redeltaall
+ re-delta-all
deltas within internal storage will always be recalculated without reusing prior deltas; this will likely make execution run several times slower; this optimization is typically not needed
- redeltafulladd
- every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "redeltaall" but even slower since more logic is involved.
+ re-delta-fulladd
+ every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "re-delta-all" but even slower since more logic is involved.
--optimize can be used to add optimizations
@@ -153,20 +153,51 @@ An upgrade of a repository created with
requirements
preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store
- redeltaparent
+ re-delta-parent
deltas within internal storage will choose a new base revision if needed
additional optimizations are available by specifying "--optimize <name>":
- redeltamultibase
+ re-delta-multibase
deltas within internal storage will be recalculated against multiple base revision and the smallest difference will be used; the size of the repository may shrink significantly when there are many merges; this optimization will slow down execution in proportion to the number of merges in the repository and the amount of files in the repository; this slow down should not be significant unless there are tens of thousands of files and thousands of merges
- redeltaall
+ re-delta-all
deltas within internal storage will always be recalculated without reusing prior deltas; this will likely make execution run several times slower; this optimization is typically not needed
- redeltafulladd
- every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "redeltaall" but even slower since more logic is involved.
+ re-delta-fulladd
+ every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "re-delta-all" but even slower since more logic is involved.
+
+
+modern form of the option
+
+ $ hg debugupgrade --optimize re-delta-parent
+ (no feature deficiencies found in existing repository)
+ performing an upgrade with "--run" will make the following changes:
+
+ requirements
+ preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store
+
+ re-delta-parent
+ deltas within internal storage will choose a new base revision if needed
+ additional optimizations are available by specifying "--optimize <name>":
+
+ re-delta-multibase
+ deltas within internal storage will be recalculated against multiple base revision and the smallest difference will be used; the size of the repository may shrink significantly when there are many merges; this optimization will slow down execution in proportion to the number of merges in the repository and the amount of files in the repository; this slow down should not be significant unless there are tens of thousands of files and thousands of merges
+
+ re-delta-all
+ deltas within internal storage will always be recalculated without reusing prior deltas; this will likely make execution run several times slower; this optimization is typically not needed
+
+ re-delta-fulladd
+ every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "re-delta-all" but even slower since more logic is involved.
+
+
+unknown optimization:
+
+ $ hg debugupgrade --optimize foobar
+ abort: unknown optimization action requested: foobar
+ (run without arguments to see valid optimizations)
+ [255]
Various sub-optimal detections work
@@ -243,17 +274,17 @@ Various sub-optimal detections work
additional optimizations are available by specifying "--optimize <name>":
- redeltaparent
+ re-delta-parent
deltas within internal storage will be recalculated to choose an optimal base revision where this was not already done; the size of the repository may shrink and various operations may become faster; the first time this optimization is performed could slow down upgrade execution considerably; subsequent invocations should not run noticeably slower
- redeltamultibase
+ re-delta-multibase
deltas within internal storage will be recalculated against multiple base revision and the smallest difference will be used; the size of the repository may shrink significantly when there are many merges; this optimization will slow down execution in proportion to the number of merges in the repository and the amount of files in the repository; this slow down should not be significant unless there are tens of thousands of files and thousands of merges
- redeltaall
+ re-delta-all
deltas within internal storage will always be recalculated without reusing prior deltas; this will likely make execution run several times slower; this optimization is typically not needed
- redeltafulladd
- every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "redeltaall" but even slower since more logic is involved.
+ re-delta-fulladd
+ every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "re-delta-all" but even slower since more logic is involved.
$ hg --config format.dotencode=false debugupgraderepo
@@ -291,17 +322,17 @@ Various sub-optimal detections work
additional optimizations are available by specifying "--optimize <name>":
- redeltaparent
+ re-delta-parent
deltas within internal storage will be recalculated to choose an optimal base revision where this was not already done; the size of the repository may shrink and various operations may become faster; the first time this optimization is performed could slow down upgrade execution considerably; subsequent invocations should not run noticeably slower
- redeltamultibase
+ re-delta-multibase
deltas within internal storage will be recalculated against multiple base revision and the smallest difference will be used; the size of the repository may shrink significantly when there are many merges; this optimization will slow down execution in proportion to the number of merges in the repository and the amount of files in the repository; this slow down should not be significant unless there are tens of thousands of files and thousands of merges
- redeltaall
+ re-delta-all
deltas within internal storage will always be recalculated without reusing prior deltas; this will likely make execution run several times slower; this optimization is typically not needed
- redeltafulladd
- every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "redeltaall" but even slower since more logic is involved.
+ re-delta-fulladd
+ every revision will be re-added as if it was new content. It will go through the full storage mechanism giving extensions a chance to process it (eg. lfs). This is similar to "re-delta-all" but even slower since more logic is involved.
$ cd ..
@@ -480,7 +511,7 @@ store files with special filenames aren'
requirements
preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store
- redeltafulladd
+ re-delta-fulladd
each revision will be added as new content to the internal storage; this will likely drastically slow down execution time, but some extensions might need it
beginning upgrade...
@@ -692,7 +723,7 @@ repository config is taken in account
requirements
preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store
- redeltaall
+ re-delta-all
deltas within internal storage will be fully recomputed; this will likely drastically slow down execution time
beginning upgrade...
More information about the Mercurial-devel
mailing list