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
