On Mon, Dec 31, 2012 at 4:22 AM, Miriam Hochwald
<miriamhochwald_at_gmail.com>wrote:
> I am new to this random public email writing ... and, at least for me it
> takes a fair amount of courage to do so. I have had to face a few phobia
> barriers based on experience.
>
Welcome! It can indeed be quite scary at first...then, you just give in
and hope no one looks at your initial posts a decade from now. =)
> I am interested in contributing to the project:
> *
> *
> *“Improve progress output displayed during update and commit.”*
>
> I have written an approach towards it as follows:
>
> This is basically a Human Computer Interaction (HCI) problem combined
> with understanding the code, and estimating or updating the time it takes
> to complete a file packet transfer. The user needs to be provided with more
> detailed progress information for ‘svn’ commands, so they know how much
> longer they need to wait. This feature is very important, especially for
> GUI clients. Currently there are a rudimentary series of dots, one dot per
> file with a filename after each complete file. This approach provides
> insufficient visual communication regarding the percentage of the total
> size to transmit, or the total number of files to transmit. In general
> this is an interface change, which could be approached such that it
> refrains form disturbing the existing parsers of ‘svn commit’ output. Some
> progress information is available such as the number of bytes or progress
> of a data chunk to be transferred. Missing from the equation is the number
> of files/ chunks that need to be transferred and how many already are
> transferred. For when doing a ‘svn up’, there is no way of telling the user
> whether it will take seconds, minutes or hours until the update will be
> complete if a lot has been changed. One approach could be to increase the
> granularity of update feedback. For example there could be progress bar
> feedback for every 50K in either direction. Alternately, since it is known
> how many files there are to transmit, a progress bar could indicate the
> number of files successfully transferred as a percentage of the total
> counted. For each file DeltaV knows the data to be transmit, so a progress
> bar could be established for it.
>
Yup, ra_serf (what we use on the client-side for HTTP/pseudo-DeltaV) has a
pretty good idea what the overall file size is and how much has been
written on the wire (when committing) or receiving (when updating). We've
always just copped out with one dot per file at the notification - it's
always been an annoyance to me that we haven't come up with a better
mechanism - some files are 1KB and some doofuses like to commit binary 30MB
JAR files (looking at you Java devs!) - yet, both are represented with one
dot. So, I look forward to what you come up with here! I don't know how
much we'll be able to improve ra_svn - my hunch is that it'd be easier to
get it working with ra_serf first and then come back to ra_svn after you
have all of the notification APIs updated.
If what I just wrote doesn't make complete sense yet, don't panic - after
you get more acquainted with the source code, the paragraph above should
make more sense! =)
> As yet I am still setting up the development environment, working through
> the follow instructions:
>
> http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
>
> Putting together all these bits and bods seems quite foreign to me, and is
> quite confronting. So, I am hopeful that people in this community can be
> supportive and understanding of a learning/ experience gap ... as I trail
> blaze into something I haven't tried before.
>
If you see anywhere in the INSTALL documentation that isn't clear, ask!
That documentation is intended for new contributors like you - so, if it
doesn't make sense, let us know. Even better, submit patches to the
INSTALL docs. =)
> I look forward to getting to know some of you in the near future.
>
Same here! -- justin
Received on 2013-01-02 03:31:00 CET