Show More
@@ -348,6 +348,19 b' def finddeficiencies(repo):' | |||
|
348 | 348 | |
|
349 | 349 | return deficiencies |
|
350 | 350 | |
|
351 | # search without '-' to support older form on newer client. | |
|
352 | # | |
|
353 | # We don't enforce backward compatibility for debug command so this | |
|
354 | # might eventually be dropped. However, having to use two different | |
|
355 | # forms in script when comparing result is anoying enough to add | |
|
356 | # backward compatibility for a while. | |
|
357 | legacy_opts_map = { | |
|
358 | 'redeltaparent': 're-delta-parent', | |
|
359 | 'redeltamultibase': 're-delta-multibase', | |
|
360 | 'redeltaall': 're-delta-all', | |
|
361 | 'redeltafulladd': 're-delta-fulladd', | |
|
362 | } | |
|
363 | ||
|
351 | 364 | def findoptimizations(repo): |
|
352 | 365 | """Determine optimisation that could be used during upgrade""" |
|
353 | 366 | # These are unconditionally added. There is logic later that figures out |
@@ -355,7 +368,7 b' def findoptimizations(repo):' | |||
|
355 | 368 | optimizations = [] |
|
356 | 369 | |
|
357 | 370 | optimizations.append(improvement( |
|
358 | name='redeltaparent', | |
|
371 | name='re-delta-parent', | |
|
359 | 372 | type=optimisation, |
|
360 | 373 | description=_('deltas within internal storage will be recalculated to ' |
|
361 | 374 | 'choose an optimal base revision where this was not ' |
@@ -368,7 +381,7 b' def findoptimizations(repo):' | |||
|
368 | 381 | 'base revision if needed'))) |
|
369 | 382 | |
|
370 | 383 | optimizations.append(improvement( |
|
371 | name='redeltamultibase', | |
|
384 | name='re-delta-multibase', | |
|
372 | 385 | type=optimisation, |
|
373 | 386 | description=_('deltas within internal storage will be recalculated ' |
|
374 | 387 | 'against multiple base revision and the smallest ' |
@@ -385,7 +398,7 b' def findoptimizations(repo):' | |||
|
385 | 398 | 'significantly'))) |
|
386 | 399 | |
|
387 | 400 | optimizations.append(improvement( |
|
388 | name='redeltaall', | |
|
401 | name='re-delta-all', | |
|
389 | 402 | type=optimisation, |
|
390 | 403 | description=_('deltas within internal storage will always be ' |
|
391 | 404 | 'recalculated without reusing prior deltas; this will ' |
@@ -396,12 +409,12 b' def findoptimizations(repo):' | |||
|
396 | 409 | 'execution time'))) |
|
397 | 410 | |
|
398 | 411 | optimizations.append(improvement( |
|
399 | name='redeltafulladd', | |
|
412 | name='re-delta-fulladd', | |
|
400 | 413 | type=optimisation, |
|
401 | 414 | description=_('every revision will be re-added as if it was new ' |
|
402 | 415 | 'content. It will go through the full storage ' |
|
403 | 416 | 'mechanism giving extensions a chance to process it ' |
|
404 | '(eg. lfs). This is similar to "redeltaall" but even ' | |
|
417 | '(eg. lfs). This is similar to "re-delta-all" but even ' | |
|
405 | 418 | 'slower since more logic is involved.'), |
|
406 | 419 | upgrademessage=_('each revision will be added as new content to the ' |
|
407 | 420 | 'internal storage; this will likely drastically slow ' |
@@ -654,20 +667,20 b' def _upgraderepo(ui, srcrepo, dstrepo, r' | |||
|
654 | 667 | ui.write(_('(it is safe to interrupt this process any time before ' |
|
655 | 668 | 'data migration completes)\n')) |
|
656 | 669 | |
|
657 | if 'redeltaall' in actions: | |
|
670 | if 're-delta-all' in actions: | |
|
658 | 671 | deltareuse = revlog.revlog.DELTAREUSENEVER |
|
659 | elif 'redeltaparent' in actions: | |
|
672 | elif 're-delta-parent' in actions: | |
|
660 | 673 | deltareuse = revlog.revlog.DELTAREUSESAMEREVS |
|
661 | elif 'redeltamultibase' in actions: | |
|
674 | elif 're-delta-multibase' in actions: | |
|
662 | 675 | deltareuse = revlog.revlog.DELTAREUSESAMEREVS |
|
663 | elif 'redeltafulladd' in actions: | |
|
676 | elif 're-delta-fulladd' in actions: | |
|
664 | 677 | deltareuse = revlog.revlog.DELTAREUSEFULLADD |
|
665 | 678 | else: |
|
666 | 679 | deltareuse = revlog.revlog.DELTAREUSEALWAYS |
|
667 | 680 | |
|
668 | 681 | with dstrepo.transaction('upgrade') as tr: |
|
669 | 682 | _copyrevlogs(ui, srcrepo, dstrepo, tr, deltareuse, |
|
670 | 'redeltamultibase' in actions) | |
|
683 | 're-delta-multibase' in actions) | |
|
671 | 684 | |
|
672 | 685 | # Now copy other files in the store directory. |
|
673 | 686 | # The sorted() makes execution deterministic. |
@@ -731,7 +744,9 b' def _upgraderepo(ui, srcrepo, dstrepo, r' | |||
|
731 | 744 | |
|
732 | 745 | def upgraderepo(ui, repo, run=False, optimize=None): |
|
733 | 746 | """Upgrade a repository in place.""" |
|
734 | optimize = set(optimize or []) | |
|
747 | if optimize is None: | |
|
748 | optimize = [] | |
|
749 | optimize = set(legacy_opts_map.get(o, o) for o in optimize) | |
|
735 | 750 | repo = repo.unfiltered() |
|
736 | 751 | |
|
737 | 752 | # Ensure the repository can be upgraded. |
@@ -131,17 +131,17 b' An upgrade of a repository created with ' | |||
|
131 | 131 | |
|
132 | 132 | additional optimizations are available by specifying "--optimize <name>": |
|
133 | 133 | |
|
134 | redeltaparent | |
|
134 | re-delta-parent | |
|
135 | 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 | 136 | |
|
137 | redeltamultibase | |
|
137 | re-delta-multibase | |
|
138 | 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 | 139 | |
|
140 | redeltaall | |
|
140 | re-delta-all | |
|
141 | 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 | 142 | |
|
143 | redeltafulladd | |
|
144 | 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. | |
|
143 | re-delta-fulladd | |
|
144 | 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. | |
|
145 | 145 | |
|
146 | 146 | |
|
147 | 147 | --optimize can be used to add optimizations |
@@ -153,20 +153,51 b' An upgrade of a repository created with ' | |||
|
153 | 153 | requirements |
|
154 | 154 | preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store |
|
155 | 155 | |
|
156 | redeltaparent | |
|
156 | re-delta-parent | |
|
157 | 157 | deltas within internal storage will choose a new base revision if needed |
|
158 | 158 | |
|
159 | 159 | additional optimizations are available by specifying "--optimize <name>": |
|
160 | 160 | |
|
161 | redeltamultibase | |
|
161 | re-delta-multibase | |
|
162 | 162 | 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 |
|
163 | 163 | |
|
164 | redeltaall | |
|
164 | re-delta-all | |
|
165 | 165 | 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 |
|
166 | 166 | |
|
167 | redeltafulladd | |
|
168 | 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. | |
|
167 | re-delta-fulladd | |
|
168 | 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. | |
|
169 | ||
|
170 | ||
|
171 | modern form of the option | |
|
172 | ||
|
173 | $ hg debugupgrade --optimize re-delta-parent | |
|
174 | (no feature deficiencies found in existing repository) | |
|
175 | performing an upgrade with "--run" will make the following changes: | |
|
176 | ||
|
177 | requirements | |
|
178 | preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store | |
|
179 | ||
|
180 | re-delta-parent | |
|
181 | deltas within internal storage will choose a new base revision if needed | |
|
169 | 182 | |
|
183 | additional optimizations are available by specifying "--optimize <name>": | |
|
184 | ||
|
185 | re-delta-multibase | |
|
186 | 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 | |
|
187 | ||
|
188 | re-delta-all | |
|
189 | 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 | |
|
190 | ||
|
191 | re-delta-fulladd | |
|
192 | 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. | |
|
193 | ||
|
194 | ||
|
195 | unknown optimization: | |
|
196 | ||
|
197 | $ hg debugupgrade --optimize foobar | |
|
198 | abort: unknown optimization action requested: foobar | |
|
199 | (run without arguments to see valid optimizations) | |
|
200 | [255] | |
|
170 | 201 | |
|
171 | 202 | Various sub-optimal detections work |
|
172 | 203 | |
@@ -243,17 +274,17 b' Various sub-optimal detections work' | |||
|
243 | 274 | |
|
244 | 275 | additional optimizations are available by specifying "--optimize <name>": |
|
245 | 276 | |
|
246 | redeltaparent | |
|
277 | re-delta-parent | |
|
247 | 278 | 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 |
|
248 | 279 | |
|
249 | redeltamultibase | |
|
280 | re-delta-multibase | |
|
250 | 281 | 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 |
|
251 | 282 | |
|
252 | redeltaall | |
|
283 | re-delta-all | |
|
253 | 284 | 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 |
|
254 | 285 | |
|
255 | redeltafulladd | |
|
256 | 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. | |
|
286 | re-delta-fulladd | |
|
287 | 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. | |
|
257 | 288 | |
|
258 | 289 | |
|
259 | 290 | $ hg --config format.dotencode=false debugupgraderepo |
@@ -291,17 +322,17 b' Various sub-optimal detections work' | |||
|
291 | 322 | |
|
292 | 323 | additional optimizations are available by specifying "--optimize <name>": |
|
293 | 324 | |
|
294 | redeltaparent | |
|
325 | re-delta-parent | |
|
295 | 326 | 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 |
|
296 | 327 | |
|
297 | redeltamultibase | |
|
328 | re-delta-multibase | |
|
298 | 329 | 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 |
|
299 | 330 | |
|
300 | redeltaall | |
|
331 | re-delta-all | |
|
301 | 332 | 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 |
|
302 | 333 | |
|
303 | redeltafulladd | |
|
304 | 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. | |
|
334 | re-delta-fulladd | |
|
335 | 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. | |
|
305 | 336 | |
|
306 | 337 | |
|
307 | 338 | $ cd .. |
@@ -480,7 +511,7 b" store files with special filenames aren'" | |||
|
480 | 511 | requirements |
|
481 | 512 | preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store |
|
482 | 513 | |
|
483 | redeltafulladd | |
|
514 | re-delta-fulladd | |
|
484 | 515 | 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 |
|
485 | 516 | |
|
486 | 517 | beginning upgrade... |
@@ -692,7 +723,7 b' repository config is taken in account' | |||
|
692 | 723 | requirements |
|
693 | 724 | preserved: dotencode, fncache, generaldelta, revlogv1, sparserevlog, store |
|
694 | 725 | |
|
695 | redeltaall | |
|
726 | re-delta-all | |
|
696 | 727 | deltas within internal storage will be fully recomputed; this will likely drastically slow down execution time |
|
697 | 728 | |
|
698 | 729 | beginning upgrade... |
General Comments 0
You need to be logged in to leave comments.
Login now