Locally cloning part of a large repo with e.g. $ hg clone mylocalhg hg2 -r stable shows rapidly alternating progress bars between bundling [======> manifests [============> Where 'bundling' intersperses itself in the changeset, manifest, and file progress bars. (hg version 1bb2a56a9d73)
I think Augie has some unsubmitted patches to fix this.
I look at this every so often. timeless and I made a lot of progress towards understanding the problem, but I don't know that we came up with a compelling solution.
Last I heard, there was an issue that progress bars generated in concurrent generators were in conflict. So we can either do: - explicit priority - first come, first serve - last come, first serve But at any rate, it seems there needs to be a global notion of "highest priority progress bar" and other updates aren't displayed until that one is closed.
I've got a fix for this that I'll mail post-1.9. Sorry I got to it too late for the 1.9 cycle.
See http://selenic.com/repo/hg/rev/ec4ba216ddef Augie Fackler <durin42@gmail.com> progress: make progress bar a singleton to avoid double-progress ui bugs
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:18 EDT --- This bug was previously known as _bug_ 2698 at http://mercurial.selenic.com/bts/issue2698
Fixed by https://mercurial-scm.org/repo/hg/rev/f428c347d32b Jun Wu <quark@fb.com> progress: remove progress.estimate config It was introduced by 98e4d39 ("progress: add speed format" 2011-5-9) and was intended to hide ETA information for the first few seconds. Later 5d261fd ("progress: add a changedelay to prevent parallel topics from flapping (issue2698)" 2011-6-23) introduced `changedelay` config which hides the entire progress bar for the first few seconds. So `progress.estimate` seems somehow duplicated feature-wise. Since it's experimental and duplicated, let's just remove it. This makes the next patch simpler - it no longer needs to make sure `starttimes` is the real start time. Differential Revision: https://phab.mercurial-scm.org/D828 (please test the fix)
Bug was set to TESTING for 14 days, resolving