changeset 41088:5608b5a6c323

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.
author Boris Feld <boris.feld@octobus.net>
date Fri, 13 Jul 2018 03:05:30 +0200
parents 797a416a91bd
children a59a74721c76
files mercurial/upgrade.py tests/test-upgrade-repo.t
diffstat 2 files changed, 79 insertions(+), 33 deletions(-) [+]
line wrap: on
line diff
--- a/mercurial/upgrade.py	Fri Dec 21 05:27:30 2018 +0100
+++ b/mercurial/upgrade.py	Fri Jul 13 03:05:30 2018 +0200
@@ -348,6 +348,19 @@
 
     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 @@
     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 @@
                          '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 @@
                          '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 @@
                          '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 @@
     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, 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.
--- a/tests/test-upgrade-repo.t	Fri Dec 21 05:27:30 2018 +0100
+++ b/tests/test-upgrade-repo.t	Fri Jul 13 03:05:30 2018 +0200
@@ -131,17 +131,17 @@
   
   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 @@
   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 @@
   
   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 @@
   
   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 @@
   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 @@
   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...