Hao Zhang wrote:
> Hi, all. I'm a postgraduate on CS. I would like to pick up the subject 'Show progress output' as my GSOC project.
>
> After using SVN for nearly two years, I would love to do some contribution to the good VCS. I have collect some information about this feature, wish for some advice and comments.
>
> As the Issue #901 mentioned, when update, check in or out a huge bytes, users can just see a lot of dots or a long list of files. This is a bit dull. If a progress indicator gives a percentage of the total size to transmit, or the total number of files to transmit, users will be happy.
>
> A.What info available for this feature.
>
> As to this feature, its function is in some degree determined by what information we can get from the context. Some discussions before shows us:
> 1. Amount of files to transmit is known.
>
By "transmit", I assume you mean "transmit or receive"? I think a
progress reporter should deal with traffic in both directions not just
from client to server. (Though the server->client part is more complex,
since the protocols are streamy.)
> 2. Amount of all data to transmit is unknown.
>
Actually, in general, the exact amount of data to transmit per file will
not be known until deltas are computed. Also, the computation time is
not always insignificant -- there are probably some operations where the
time to calculate the result is longer than the time to transmit it.
> 3. Amount of data per file is known by Neon.
>
Or serf, or svnserve, or local BDB or FSFS back-ends ... a progress
meter should deal with more than just Neon/HTTP
> 4. Amount of data what has been transmitted per file is certainly known.
> 5. Amount of data what has been transmitted altogether is certainly known.
>
> As the discussions I found is a bit old, some were created years ago. I don't know what's the situation in the newest version, wish for your comments about them, or show me where to found more info. Oh, I have found the struct svn_client_ctx_t in svn_client.h, but the more, the better!
>
> B. My Initial ideas
>
> 1. The progress bar should be launched after a threshold time (several seconds).
> 2. Show a sub-progress indicator per file to suite huge files or weak network access.
>
These are command-line-specific design details :) but worth mentioning.
However, before you design fancy progress meters, you should consider
how they interact with the current comman-line output. The output of SVN
commands is meant to be easily parseable by wrapper scripts, etc; the
progress meter must not break that feature.
> 3. Some kind of callback function should be defined to simplify third party GUI tools to use.
>
I suggest that this is the more important part of the task, and in fact
the more complex one. I actually recommend you split the proposal into
two parts:
* the first that deals with all the necessary work to create a
progress-reporting callback;
* the second would be about actually implementing a progress
reporter for the command-line client.
Both tasks have a range of solutions, from trivial/imprecise (e.g.,
don't adjust progress percentage for actual transmitted delta size) to
very complex indeed. Given the relatively short amount of time
available, it's a a good idea to limit your SoC proposal to something
that's a) immediately useful, and b) likely to succeed. In my opinion,
it's better to invest time into a good reporting callback, even to the
point of not doing a progress bar for the cmdline client. It's actually
the better choice if you want to learn the code, it can be used by other
SVN clients, etc.
> 4. survey to collect system information and user requirement, write test cases, do the coding.
>
> C.Besides the feature, I also need some advice about getting familiar with source code of SVN, wish for some useful links or documents.
>
Hm, I guess the design doc would still be a good start, but I've no ides
how up-to-date it is.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1422023
Received on 2009-03-26 01:23:46 CET