Details
- Reviewers
pulkit - Group Reviewers
hg-reviewers - Commits
- rHG6540333acb95: synthrepo: use progress helper
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
contrib/synthrepo.py | ||
---|---|---|
178 | progress.increment()? |
contrib/synthrepo.py | ||
---|---|---|
178 | That would mean that it would now start at 1 instead of 0. I made that change in one or two other patches and then I felt unsure if that's what we want, so I left the current behavior in this and later patches. I meant to have a discussion about which behavior we want. For example, when the progress bar says 1/3, do you interpret that as processing the first item or that 1 item is already complete? A related issue is that it seems like either 0% or 100% wouldn't happen (for more than a split second, regardless of how slow each item is). Let's say we have 3 items. We can then do either of these: progress.update(0) for i [1,2,3]: progress.update(i) process(i) progress.complete() progress.update(0) for i [1,2,3]: process(i) progress.update(i) progress.complete() As you can see, either the 0/3 or the 3/3 step will never really be displayed. |
contrib/synthrepo.py | ||
---|---|---|
178 | (sorry I missed this. I have my phabricator emails turned off)
I think both :(. In network related bars where number of kbs or mbs are involved I think, 1/3 means 1 is already done. Sometimes in other processing, I think okay this one is processing. However, I think if have verbs before the progress bars saying processing, sending, recieving, in those cases processing 1/3 will mean processing the 1st item. I still don't feel strong either way but I will like to have the same meaning throughout core. |
contrib/synthrepo.py | ||
---|---|---|
178 | Another point is that when we pass an item argument (often a filename), then it's helpful to show it before starting processing of the filename, so one can tell which one is slow. Also, if we updated the progress after processing, the last item would only be printed for a spit second (no matter how long time it took to process it). For those reasons, I now lean towards updating progress before processing. For consistency, I think it makes more sense to update progress before processing also when there's no item argument. I agree about doing it after processing when it's about processed bytes, though. |
progress.increment()?