Re: request for comments from developers about issues 1004 and 901

[kf...@collab.net]

"SteveKing" <st...@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

Re: request for comments from developers about issues 1004 and 901

[kf...@collab.net]

"SteveKing" <st...@gmx.ch> writes:
> In most issues marked as post-1.0 you usually post "a patch earlier
> than 1.0 will be most welcome, of course". 
> But to make patches, some discussion is needed first.

That's true, sorry -- maybe I should be more judicious about which
issues I say that about.  For example, a small, discrete issue like
#1209 (about path escaping) is one where it's easy to review a patch
before 1.0 and just fix it.

But an issue that requires discussion and (likely) a complex fix is a
different matter.  In that case, the effort required is part of the
reason we put it in Post-1.0 in the first place.  #901 is one of
those.

> Does that mean that everything marked as post-1.0 won't be
> accepted or discussed about?

No, it means we exercise judgement on a case-by-case basis, like the
large-brained hominids we are :-).

> > 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").
> 
> Sorry, mixed up the issue numbers. And issue 1004 wasn't just
> about the cancellation if you read the opening message of the issue.

Ah, thanks for clarifying.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: request for comments from developers about issues 1004 and 901

[SteveKing <st...@gmx.ch>]

----- Original Message ----- 
From: <kf...@collab.net>
> 
> 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

In most issues marked as post-1.0 you usually post "a patch earlier
than 1.0 will be most welcome, of course". 
But to make patches, some discussion is needed first.

> 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.

Does that mean that everything marked as post-1.0 won't be
accepted or discussed about?

> 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").

Sorry, mixed up the issue numbers. And issue 1004 wasn't just
about the cancellation if you read the opening message of the issue.

Stefan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org