Stefan Küng wrote on Sat, 2 Aug 2008 at 13:31 +0200:
> Daniel Shahaf wrote:
> > Stefan Küng wrote on Sat, 2 Aug 2008 at 12:40 +0200:
> > > Daniel Shahaf wrote:
> > > > As I read it, it promises the (current) ra_svn behaviour.
> > > Yes, but it works not the same way as neon and serf. Since the
> > > callback for neon is actually done in the neon library, we can't
> > > change that.
> >
> > We could write a wrapper callback that manipulates (sums) what neon
> > reports.
>
> But that would break the compatibility.
> Progress info for ra_svn was added in 1.5, while it was available for
> ra_neon in 1.3.
>
This convinces me; it's better to break compat with ra_svn_at_1.5.0 than
with ra_neon_at_1.3.0. (It also explains how no one spotted this bug
before.)
> >
> > > Neon does it this way because it can 'restart' when needed. For
> > > example, most of the time the total is not known beforehand. But
> > > sometimes it is. Neon then fills in the 'total' param (instead of
> > > passing -1 there) and starts counting the bytes again.
> > >
> >
> > I'm not familiar with 'restarts' in this context. From your description
> > it sounds that they have to do with how neon calculates the number of
> > bytes it has transferred, not with whether it chooses to report that
> > number directly or as a difference since the preceding reported amount.
> >
> > Am I missing something?
>
> An example (pseudo-checkout):
> callback(200, -1) // for connecting
> callback(300, -1) // for info packets
> callback(512, 123000) // first file
> callback(512, 123000) // first file
> callback(512, 123000) // first file
> ...
> callback(30, 123000) // first file
> callback(300, -1) // for info packets
> callback(512, 234000) // second file
> callback(512, 234000) // second file
> callback(512, 234000) // second file
> ...
> callback(30, 234000) // second file
>
> Does this explain it more clear? If not, just ask.
>
I don't understand anything here. The 'total' values you provide are
not very helpful -- they are neither a lower bound nor an upper bound on
the number of bytes that will be transferred -- so what *do* they mean?
(They are not a lower bound because the last callback() on the last file
will still report that file's size as 'total'. They are not an upper
bound because after the series of calls for the first file, with
total=123000, comes another file.)
For reference, svn_ra_progress_notify_func_t's says that "@a total is
the total number of bytes to transfer or -1 if it's not known".
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-02 14:21:53 CEST