[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Suggestion for SoC

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-04-24 18:26:13 CEST

Justin Erenkrantz wrote:
> On 4/24/06, Erik Huelsmann <ehuels@gmail.com> wrote:
>> So, what I was thinking about is to add window-level (as in svndiff
>> window) or block level (as in SVN__STREAM_BLOCK_SIZE) notifications to
>> all RA transfers. Meaning: commit, update, import, cat, diff, merge,
>> (what other functions do file transfers?)
>
> ra_dav/neon and ra_serf /serf just take the file handle with the
> changes and deliver it via a PUT. There's no way to get feedback from
> them as to the progress within one file. There's a reason why this
> hasn't been done before... -- justin

I know that. I've tried to make the best of it with neon. That's what's
implemented now - not very good but better than nothing. At least I can
show the user some transfer speed.

What would be needed is to pass a structure from e.g. svn_client_ctx_t
down to every ra module. Currently, that's not done (and I don't know if
it would be accepted to include that header file in the ra modules).
If that's done, then a 'higher' module can fill in the data into that
structure (e.g. number of total files to transmit, including total
bytes), then the ra modules can fill in the data they know (transferred
bytes) and call a callback function which informs the client about it.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 24 18:26:49 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.