"SteveKing" <steveking@gmx.ch> writes:
> I already tried twice
> (http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=42729
> and as a comment to issue 901 itself) to get some comments from developers
> here
> but got no luck so far. Not _one_ single reply yet. So if noone replies
> this time I'll give up for good.
I think the reason you're not getting much feedback is that the issue
is listed as "Post-1.0". This is because we (or at least I) felt the
effort required to solve the issue was not worth the benefit at this
time. If there were no pressure to stabilize and release 1.0, things
might be different.
You'll probably get much more response if you post patches for pre-1.0
issues :-).
By the way, I don't see in the history of issue 901 where it "got
closed". Issue 1004 was closed, but as you say, that was about
cancellation checking, not progress reporting. But issue 901 looks
like it's still new (i.e., just opened, not "reopened").
-Karl
> Both issues 1004 and 901 are about the same
> request: more detailed progress information for
> svn commands. Issue 901 got closed, but I think
> it was closed too early. The initial request wasn't
> for a cancellation function (to which it was later
> changed to).
>
> Since this feature is very important especially
> for GUI clients I'd like to make a suggestion:
>
> add a new callback function to svn_client_ctx_t
>
> svn_progress_notify_func_t progress_func;
> void *progress_baton;
>
> the progess function would look like this:
>
> typedef void (*svn_progress_notify_func_t)
> (void *baton,
> const char * url1,
> const char * url2,
> svn_progress_val_t item_progress,
> svn_progress_val_t item_total,
> svn_progress_unit,
> svn_progress_val_t overall_progress,
> svn_progress_val_t overall_total,
> svn_progress_unit);
>
> with svn_progress_val_t being an unsigned long and
> svn_progress_unit being an enum with members
> like "bytes", "nothing" (for just displaying percent values),
> "files", etc.
>
> A little explanation for the callback parameters:
> url1 and url2 would be either filepaths or urls, while
> url1 is the source and url2 the destination. Clients would
> use that information just for showing the user on what
> items the function is currently working on. If not used,
> they have to be NULL so the client knows that there's
> no information.
>
> item_progress and item_total would be the progress
> of a single item (for operations which work on
> multiple files/urls). item_progress indicates e.g.
> how many bytes of a file are already transferred, and
> item_total would be the total amount of bytes the file
> has. If for example the total isn't known then item_total
> would be null. That way a client still can display
> some information (like "14kB transferred").
>
> overall_progress and overall_total is the progress pair
> for the whole operation. It doesn't need to be related
> to the values used in item_progress/item_total but can
> be completely independent values. E.g. if the item values
> specify bytes of a file, the overall values could be just
> the number of files - it doesn't need to be the total bytes
> of all files. Here too, if the values are not know by
> subversion keep them null.
>
> The first step would be to extend the svn_client_ctx_t
> structure. No change in the main functions need to be
> done in this first step.
>
> Then step by step the different svn functions
> could start using that callback if it's usefull.
>
> That way the feature could be implemented in small
> steps, without the risk of breaking too much.
> Also, the API change would be done before beta.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 11 17:49:10 2003