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

Re: Progress-meter and download-speed when updating.

From: Christian Rasmussen <chr.aaroe_at_gmail.com>
Date: Wed, 4 Jun 2008 03:23:18 +0200

Ok, so what I get from that is that it's not a direct in feature in a clean
svn installation but something which can be achieved with neon?

And to comment on epg who said I meant that the information was visible when
committing, I must emphasize that I really did mean to update. I just tried
it out on the repository I wrote earlier and it really is when updating.

What I'm really curious about is how to achieve this with my server, because
this could really be quite informative at times and I can't seem to find
anything with google - not that I expect a guide, but just to know if I'm
correct with me understanding that it's by this neon-thingy?

Thanks for your reply, it is very much appreciated.
Christian Aarų Rasmussen

On Wed, Jun 4, 2008 at 3:15 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:

> "Christian Rasmussen" <chr.aaroe_at_gmail.com> writes:
> > Yup, exactly the same TortoiseSVN version. Don't know about the server
> version
> > which software or version is running. The repository where I noticed it
> was
> > this: http://svn.astrumfutura.org/zfblog/ . I myself is just using a
> plain
> > version of svn on my gentoo - the newest version available through
> portage.
> In IRC just now, epg and I had this conversation:
> <kfogel> Huh. Anyone see that guy's post on users@ just now about
> how TortoiseSVN gave him a progress report ("file x of y") while
> updating?
> <kfogel> Is that just a Tortoise improvement, or did we add some kind
> of server support for this at some point?
> <kfogel> Client could do it alone, of course, but it would be more
> efficient with server help.
> <kfogel> There's r29484...
> <epg> not for updates
> <epg> he says "update a repository", he means commit
> <epg> the neon commit progress report is better than the ra-svn one
> <epg> but only because it writes to a tmp file first and then sends
> that over; ra-svn is streamy, and therefore doesn't knwo the size of
> what it's sending
> <epg> i don't know how serf's progress reporting works; it didn't
> support it at all when i was testing gvn progress reporting
> ("gvn" is another subversion client, see http://code.google.com/p/gvn/)
> This doesn't answer your question, but it clarifies it.
> -Karl
> > On Wed, Jun 4, 2008 at 2:46 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> >
> > "Christian Rasmussen" <chr.aaroe_at_gmail.com> writes:
> > > For quite some time now I've been hosting a subversion server for
> my
> > > friends who I study with for use with our projects. Everything has
> > > worked like a charm but something I've always have been a bit
> annoyed
> > > with was the fact that I wasn't able to view how far in the process
> I
> > > was when updating my repository - e.g. file x of y.
> > >
> > > A little while ago I was updating another repository for some
> > > source-forge project and was amazed that this information was
> suddenly
> > > visible when I was updating.
> > >
> > > I've always been using TortoiseSVN and I'm hosting my svn on a
> Gentoo
> > > box where I haven't been able to find anything in the config files
> > > regarding this matter.
> > >
> > > So, how do I get this information to be shown when using my server?
> >
> > Were you using the same version of TortoiseSVN both times? And
> > configured the same way?
> >
> > This can be implemented entirely on the client side (though if the
> > server were to help, the whole thing could be done more efficiently,
> > latency-wise). So it may have nothing to do with the repository.
> >
> > If we had exact URLs, an exact transcript, client version numbers,
> etc,
> > that would help :-).
> >
> > Note: not sure if r29484 is relevant to this.
> >
> > -Karl
Received on 2008-06-04 03:24:22 CEST

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

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