Mercurial > public > mercurial-scm > hg
diff tests/test-upgrade-repo.t @ 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 | 3764330f76a6 |
| children | a59a74721c76 |
line wrap: on
line diff
--- 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...