On 4/21/06, Stefan K√ľng <email@example.com> wrote:
> Since there's some discussion about what issues could be used for SoC,
> I'd like to add one more:
> Issue #901 : http://subversion.tigris.org/issues/show_bug.cgi?id=901
[ Issue 901: show progress information during commit ]
I second this request, though possibly 'during commit' is too strict.
For performance testing libsvn_wc I have used 3 CD files. The full
commit (after 'svn add') with a local repository takes 3/4 of an hour
during which there is hardly any progress information. Sometimes it's
hard to distinguish drive activity from svn from swapping activity.
So, in (though rare) circumstances, this is good for the cli too.
> Now, this issue is almost four years old. The reason I think it's still
> open is that the command line client doesn't really need it, or it's not
> very important for it. But there are many UI clients out there which
> really need this. Users of UI programs are used to get some feedback
> about what's going on, and if they don't they're not comfortable.
> Imagine you go to sourceforge, click on a 10MB file for downloading it
> and you won't see anything (maybe only "please wait while download is in
> progress") until the file is completely downloaded or failed. You expect
> from a browser to show you how far along the download is, how fast the
> download is going, and how long it will approx. take until it's finished.
> With Subversion, that's currently not possible. Ok, I've implemented
> some very basic info for ra_dav, but ra_svn and ra_file still don't give
> any feedback. And of course, the ra_dav feedback is only good for
> showing the data transfer speed. There's no indication on how much data
> has to be sent/received for the whole operation.
Reporting the total commit size is technically somewhat different from
progress reporting, the former being *before* the commit starts (or at
least the transfer) while the latter typically is during the file
> I think this issue is big enough to keep a student busy during the
> summer, but still not so big or complicated that it couldn't be
> finished. And it can be done in stages, which is nice because even if it
> doesn't get finished the parts already done can be used.
Received on Sat Apr 22 12:15:31 2006