> -----Original Message-----
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: maandag 29 april 2013 13:31
> To: Martin Bischoff
> Cc: Ajay Pawar; users@subversion.apache.org; Thorsten Schöning
> Subject: Re: Tortoise SVN Issue Noticed
>
> On Mon, Apr 29, 2013 at 1:16 PM, Martin Bischoff <tin...@gmail.com>
> wrote:
> > On Mon, Apr 29, 2013 at 12:26 PM, Johan Corveleyn <jcor...@gmail.com>
> wrote:
> >>
> >> On Mon, Apr 29, 2013 at 12:17 PM, Thorsten Schöning
> >> <tschoen...@am-soft.de> wrote:
> >> > Guten Tag Ajay Pawar,
> >> > am Montag, 29. April 2013 um 12:08 schrieben Sie:
> >> >
> >> >> I added a new file XYZ.ppt which is of size 984 kb but still the
client
> >> >> shows 0 kb.
> >> >
> >> > As already said, Subversion uses delta transmission, compresses
> >> > content on transmission and my even use some kind of
> >> > deduplication/representation sharing on the client. I'm not sure what
> >> > exactly your problem is? Do you want to force Subversion that only
the
> >> > exact amount of data a file on your hard disk needs gets transferred?
> >> > You can't predict how much data gets transferred, simple as that.
> >>
> >> I'm wondering if this is actually an 'svn core' issue, or if this is
> >> specific to TortoiseSVN. I can't remember seeing a "transferred X KB"
> >> output when running 'svn update' on the command line. If it's
> >> TSVN-specific, it's probably better to try your luck on their
> >> mailinglist first.
> >>
> >> See here: http://tortoisesvn.net/community.html
> >>
> > There is definitely a bug in the display of the data transfer progress.
> >
> > See here for an old discussion on the tortoisesvn-users list:
> >
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess
> ageId=2991921
> >
> > But it seems the root cause is somewhere in SVN. It has to do with issue
> > 3260:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3260
> >
>
> Ah, so it's a known issue then. Thanks, that's good to know.
>
> Unfortunately, it seems no work has been done on that issue (and
> AFAICS nobody is actively working on it). Perhaps the new activity
> around this issue might motivate a developer to take it on ... Or
> perhaps someone new wants to take a closer look and maybe write a
> patch? [1]
Most of this issue is 'neon' specific and 1.8.X switches to the Serf http(s)
client by default.
Neon just sends progress data on the body of requests, not headers and most
of what is written to the server. (The progress callback is called for
different http sessions and there is no way to find out for which one the
report is). The reporting somewhat improved in 1.7, compared to the very bad
case in 1.5.
Given that, we also use optimizations for what is already in the working
copy, wire compression, plain zlib compression and several other
optimizations that makes it impossible to guess how much data would be
transferred for a specific operation.
How much data is send depends on your exact working copy (e.g. mixed
revisionness, switches, cached data); the exact client version; the exact
server version, several of their dependencies.
So depending on the output of the progress report is generally not
recommended. But clients usually want to show the difference between a stuck
connection and an active transfer. And for that case it works fine. And if
it reports the expected amount of data (for a session) it might provide some
input on how much should still be received/send.
Bert
>
> [1] http://subversion.apache.org/docs/community-
> guide/general.html#patches
>
> --
> Johan
