Summary:
Remove ui.progress as a method of updating progress. All progress bars now go
through new-style progress bars.
This also splits out the rendering of progress bars from the reporting of
progress. All tests are updated to use new-style debug progress bars, which
simply report the position of the progress bar. Rendering of progress bars
will be tested separately once the progress bar engine has been rewritten.
Reviewed By: quark-zju
Differential Revision: D7329488
fbshipit-source-id: 14f8ab67365ddd98b74986aa25d9abc7a0546144
We were wrapping the ui class again and again (uisetup, reposetup,
subrepo setup, remote repo setup, etc). We now avoid that. This has
impact on tests that were double-printing data because of this.
This drops the options to run arbitrary shell commands within
commits and the option to create a file that gets appended to
in every revision. It now supports to not write file data at
all, which is very fast for generating a pure 00changelog.i
(useful for discovery tests, for instance).
Timings for 1000 linear nodes:
* Old `hg debugbuilddag -o '+1000'` took 4.5 secs.
* New `hg debugbuilddag -o '+1000'` takes 2 secs.
* New `hg debugbuilddag '+1000'` takes 0.8 secs.
(The last one creates only 00changelog.i).
Thanks for the idea and most of the implementation to Klaus Koch
Backs revisions() and filerevs() with DAG walker which can iterate through
arbitrary list of revisions instead of strict one by one iteration from start to
stop. When a gap occurs in a revisions (i.e. in file log), the next topological
parent within the revset is searched and the connection to it is printed in the
ascii graph.
File graph can draw sometimes more connections than previous version, because
graph is produced according to the revset, not according to a file's filelog.
In case the graph contains several branches where the left parent is null, the
graphs for each are printed sequentially, not in parallel as it was a case
earlier (see for example the graph for README in hg-dev).
