Review Request: Add Progress Support for Git Clone Job

David Narváez david.narvaez at computer.org
Tue Dec 13 11:46:40 UTC 2011



> On Dec. 11, 2011, 9 a.m., Andreas Pakulat wrote:
> > This is far too simple-thought, did you actually try this out? If the cloning is non-instant the progress will jump around because git has multiple stages which all print the progress from 0 to 100%.
> > 
> > In addition you're loosing the stderr output from git clone, I'm not sure wether its logged right now, but if its not it should be so in case something goes wrong during the clone the user can see the git output.
> 
> Andreas Pakulat wrote:
>     Sorry, didn't fully read the "Testing done" part, apparently you did try this and know about the problem. I don't know how the progress is done right now, but there should be a way to tell the job-progress-meter that the job does not know how long it'll take. In that case the simple progressbar will change to one indicating that there's something going on without indicating how far it is. IMHO this is sufficient, it is an animation which clearly shows that something is going on and hence visible the job is not halted.

Progress is not done at all right now, so it's true that any solution is better than what we have right now. In order to tell the progress bar to change to a busy indicator, we would need to add some extra calls to VcsJob allowing it to specify whether it knows how log will it take to finish or not (or simply assume no VcsJob knows how long will it take and make the progress bar a busy indicator for any VCS we support).

On the other hand, that gives only half of the information. The information I am particularly interested in is knowing how much time do I have to wait in order to take other decisions like hop to next task or take a nap, whatever. As I mentioned before, having a bar that "quickly" fills at the first time, then takes a lot of time to fill in the second pass and then a fills up a third time is not so confusing once you understand what those three passes are.

The issue you raised about losing stderr output is still valid, though, I have no idea on how to solve that without doing a rather serious overhauling of output handling.

Any other comments from other developers?


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103380/#review8867
-----------------------------------------------------------


On Dec. 10, 2011, 8:55 p.m., David Narváez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103380/
> -----------------------------------------------------------
> 
> (Updated Dec. 10, 2011, 8:55 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> Very naive approach to leverage stderr to get progress. I'm no expert on QProcesses so if anything looks bad or the idea is bad as a whole, just let me know.
> 
> 
> This addresses bug 256832.
>     http://bugs.kde.org/show_bug.cgi?id=256832
> 
> 
> Diffs
> -----
> 
>   plugins/git/gitclonejob.h 3279ba1 
>   plugins/git/gitclonejob.cpp ce48ee7 
> 
> Diff: http://git.reviewboard.kde.org/r/103380/diff/diff
> 
> 
> Testing
> -------
> 
> 1. Fetch a large project using the Git provider (I tried NetworkManager, for instance)
> 2. Fetch a project using the KDE provider
> 
> In both tests, before this patch, progress is not changed until the project is completely fetched (see bug 256832). After this patch, progress bar changes with the standard error. Notice that the bar is filled three times, I'm not sure how to avoid that without making the code overly complex, but I thought it was a nice start to at least have the progress in the critical part of the process which is the second time the progress bar fills (downloading objects).
> 
> 
> Thanks,
> 
> David Narváez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20111213/0dc41b81/attachment.html>


More information about the KDevelop-devel mailing list