Ramkumar Ramachandra wrote on Tue, Sep 28, 2010 at 00:27:38 +0530:
> Hi Neels,
>
> Neels J Hofmeyr writes:
> > > I just benchmarked it recently and found that it dumps 10000 revisions
> > > of the ASF repository in 106 seconds: that's about 94 revisions per
> > > second.
> >
> > Wow! That's magnitudes better than the 5 to 10 revisions per second I'm used
> > to (I think that's using svnsync).
>
> Yep :)
>
> > While we're at it... svnsync's slowness is particularly painful when doing
> > 'svnsync copy-revprops'. With revprop changes enabled, any revprops may be
> > changed at any time. So to maintain an up-to-date mirror, one would like to
> > copy *all* revprops at the very least once per day. With a repos of average
> > corporate size, though, that can take the whole night and soon longer than
> > the developers need to go home and come back to work next morning (to find
> > the mirror lagging). So one could copy only the youngest 1000 revprops each
> > night and do a complete run every weekend. Or script a revprop-change hook
> > that propagates revprop change signals to mirrors. :(
>
> Wow. This is quite a serious problem. I'm a very new developer, and I
> don't really use Subversion. You should probably let the other
> Subversion developers know about this on a new thread?
>
> @Daniel, @Stefan: Thoughts on this?
>
Use the commits@ list and run copy-revprops only on revisions that
actually had been revprop-edited?
> > svnrdump won't help in that compartment, would it?
>
> That would be a feature request (although I'm not sure svnrdump will
> ever be extended to handle that),
How could svnrdump help here? What we might need is an RA call that has
the server provide the N last revisions to have undergone revprop edits...
> because svnrdump is still very
> young- it just dumps/ loads dumpfiles from remote repositories quickly
> at the moment. I've decided to feature freeze until I fix the perf
> issues for the upcoming release- I'll keep this in mind though.
>
> -- Ram
Received on 2010-09-28 15:50:16 CEST