Mercurial > hg
comparison tests/test-upgrade-repo.t @ 30776:3997edc4a86d
repair: determine what upgrade will do
This commit introduces code for determining what actions/improvements
an upgrade should perform.
The "upgradefindimprovements" function introduces a mechanism to
return a list of improvements that can be made to a repository.
Each improvement is effectively an action that an upgrade will
perform. Associated with each of these improvements is metadata
that will be used to inform users what's wrong and what an
upgrade will do.
Each "improvement" is categorized as a "deficiency" or an
"optimization." TBH, I'm not thrilled about the terminology and
am receptive to constructive bikeshedding. The main difference
between a "deficiency" and an "optimization" is a deficiency
is always corrected (if it deviates from the current config) and
an "optimization" is an optional action that goes above and beyond
to improve the state of the repository (usually by requiring more
CPU during upgrade).
Our initial set of improvements identifies missing repository
requirements, a single, easily correctable problem with
changelog storage, and a set of "optimizations" related to delta
recalculation.
The main "upgraderepo" function has been expanded to handle
improvements. It queries for the list of improvements and determines
which of them will run based on the current repository state and user
I went through numerous iterations of the output format before
settling on a ReST-inspired definition list format. (I used
bulleted lists in the first submission of this commit and could
not get it to format just right.) Even with the various iterations,
I'm still not super thrilled with the format. But, this is a debug*
command, so that should mean we can refine the output without BC
concerns.
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Sun, 18 Dec 2016 16:51:09 -0800 |
parents | 513d68a90398 |
children | 7de7afd8bdd9 |
comparison
equal
deleted
inserted
replaced
30775:513d68a90398 | 30776:3997edc4a86d |
---|---|
47 | 47 |
48 $ hg init disallowaddedreq | 48 $ hg init disallowaddedreq |
49 $ hg -R disallowaddedreq --config experimental.manifestv2=true --config experimental.treemanifest=true debugupgraderepo | 49 $ hg -R disallowaddedreq --config experimental.manifestv2=true --config experimental.treemanifest=true debugupgraderepo |
50 abort: cannot upgrade repository; do not support adding requirement: manifestv2, treemanifest | 50 abort: cannot upgrade repository; do not support adding requirement: manifestv2, treemanifest |
51 [255] | 51 [255] |
52 | |
53 An upgrade of a repository created with recommended settings only suggests optimizations | |
54 | |
55 $ hg init empty | |
56 $ cd empty | |
57 $ hg debugupgraderepo | |
58 (no feature deficiencies found in existing repository) | |
59 performing an upgrade with "--run" will make the following changes: | |
60 | |
61 requirements | |
62 preserved: dotencode, fncache, generaldelta, revlogv1, store | |
63 | |
64 additional optimizations are available by specifying "--optimize <name>": | |
65 | |
66 redeltaparent | |
67 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 | |
68 | |
69 redeltamultibase | |
70 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 | |
71 | |
72 redeltaall | |
73 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 | |
74 | |
75 | |
76 --optimize can be used to add optimizations | |
77 | |
78 $ hg debugupgrade --optimize redeltaparent | |
79 (no feature deficiencies found in existing repository) | |
80 performing an upgrade with "--run" will make the following changes: | |
81 | |
82 requirements | |
83 preserved: dotencode, fncache, generaldelta, revlogv1, store | |
84 | |
85 redeltaparent | |
86 deltas within internal storage will choose a new base revision if needed | |
87 | |
88 additional optimizations are available by specifying "--optimize <name>": | |
89 | |
90 redeltamultibase | |
91 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 | |
92 | |
93 redeltaall | |
94 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 | |
95 | |
96 | |
97 Various sub-optimal detections work | |
98 | |
99 $ cat > .hg/requires << EOF | |
100 > revlogv1 | |
101 > store | |
102 > EOF | |
103 | |
104 $ hg debugupgraderepo | |
105 repository lacks features recommended by current config options: | |
106 | |
107 fncache | |
108 long and reserved filenames may not work correctly; repository performance is sub-optimal | |
109 | |
110 dotencode | |
111 storage of filenames beginning with a period or space may not work correctly | |
112 | |
113 generaldelta | |
114 deltas within internal storage are unable to choose optimal revisions; repository is larger and slower than it could be; interaction with other repositories may require extra network and CPU resources, making "hg push" and "hg pull" slower | |
115 | |
116 | |
117 performing an upgrade with "--run" will make the following changes: | |
118 | |
119 requirements | |
120 preserved: revlogv1, store | |
121 added: dotencode, fncache, generaldelta | |
122 | |
123 fncache | |
124 repository will be more resilient to storing certain paths and performance of certain operations should be improved | |
125 | |
126 dotencode | |
127 repository will be better able to store files beginning with a space or period | |
128 | |
129 generaldelta | |
130 repository storage will be able to create optimal deltas; new repository data will be smaller and read times should decrease; interacting with other repositories using this storage model should require less network and CPU resources, making "hg push" and "hg pull" faster | |
131 | |
132 additional optimizations are available by specifying "--optimize <name>": | |
133 | |
134 redeltaparent | |
135 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 | |
136 | |
137 redeltamultibase | |
138 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 | |
139 | |
140 redeltaall | |
141 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 | |
142 | |
143 | |
144 $ hg --config format.dotencode=false debugupgraderepo | |
145 repository lacks features recommended by current config options: | |
146 | |
147 fncache | |
148 long and reserved filenames may not work correctly; repository performance is sub-optimal | |
149 | |
150 generaldelta | |
151 deltas within internal storage are unable to choose optimal revisions; repository is larger and slower than it could be; interaction with other repositories may require extra network and CPU resources, making "hg push" and "hg pull" slower | |
152 | |
153 repository lacks features used by the default config options: | |
154 | |
155 dotencode | |
156 storage of filenames beginning with a period or space may not work correctly | |
157 | |
158 | |
159 performing an upgrade with "--run" will make the following changes: | |
160 | |
161 requirements | |
162 preserved: revlogv1, store | |
163 added: fncache, generaldelta | |
164 | |
165 fncache | |
166 repository will be more resilient to storing certain paths and performance of certain operations should be improved | |
167 | |
168 generaldelta | |
169 repository storage will be able to create optimal deltas; new repository data will be smaller and read times should decrease; interacting with other repositories using this storage model should require less network and CPU resources, making "hg push" and "hg pull" faster | |
170 | |
171 additional optimizations are available by specifying "--optimize <name>": | |
172 | |
173 redeltaparent | |
174 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 | |
175 | |
176 redeltamultibase | |
177 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 | |
178 | |
179 redeltaall | |
180 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 | |
181 | |
182 |