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

Re: Performance comparison of svnrdump and svnsync

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 17 Aug 2011 13:55:27 -0400

On Wed, Aug 17, 2011 at 1:48 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> On Wed, Aug 17, 2011 at 01:20:33PM -0400, Mark Phippard wrote:
> > I thought I recalled when svnrdump was first created that there were some
> > timing comparisons made with svnsync that showed it to be faster at doing
> a
> > full dump/sync of a remote repository. When I test via HTTP:
> >
> > svnrdump dump http://server/repos | svnadmin load repos
> >
> > And compare this to an equivalent svnsync, I find that the times it takes
> to
> > do this is essentially the same. I then compared the HTTP access logs of
> > the server and see that the two commands produce identical logs, so
> > obviously there are not going to be big performance differences.
> >
> > Am I missing something? I realize that svnrdump still fulfills a need,
> so I
> > am not questioning the value of the tool. Just questioning whether my
> > results make sense. As I see it, for this specific scenario, someone
> would
> > be better off to still simply use svnsync for this purpose.
> Performance concerns may have been related to the use case of importing
> Subversion history into git.
> It is certainly faster to create a dump file over the network, rather
> than syncing the repository and creating a dump files from that in a
> second step.
> Not sure if that is what people were talking about though.
> Do you have a link to related discussion in the archives?

I could just be basing it on the original proposal. Maybe that planted the
seed with me that it was going to be faster:


When I mentioned it to Mike this AM, he said he thought it used the same
ra_replay as svnsync so should perform similar. It looks like that is the

Mark Phippard
Received on 2011-08-17 19:56:00 CEST

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.