Here're the test results for the basic merge repository: Subversion 1.7.0 Beta 3, binaries from collabnet Basic Tests: | 1.7.0-beta3 | rNNNNNNNN | 0:54.539 | 0:47.774 | 0:00.214 | 0:00.075 | 0:00.101 | 0:01.187 | 0:01.365
Merge Tests: | 1.7.0-beta3 | rNNNNNNNN | 0:08.154 | 0:08.984 | 0:08.402 | 0:13.511 Folder Tests: | 1.7.0-beta3 | rNNNNNNNN | 8:37.779 | 0:01.282 | 0:14.041 | 0:31.032 | 0:08.727 | 0:38.879 | 0:34.304 | 0:08.458 | 0:40.519 Binaries Tests: | 1.7.0-beta3 | rNNNNNNNN | 0:00.046 | 0:00.030 | 0:00.029 | 0:00.027 | 0:00.025 | 0:00.029 | 0:00.029 | 0:00.028 | 0:00.030 | 0:00.031 | 0:00.023 | 0:00.031 | 0:00.030 | 0:00.031 | 0:00.030 ********** Subversion 1.6.17, binaries from VisualSVN Basic Tests: | 1.6.17 | rNNNNNNNN | 0:42.548 | 0:39.758 | 0:16.504 | 0:00.257 | 0:00.105 | 0:00.637 | 0:02.445 Merge Tests: | 1.6.17 | rNNNNNNNN | 0:11.664 | 0:02.343 | 0:14.951 | 0:24.941 Folder Tests: | 1.6.17 | rNNNNNNNN | 11:58.850 | 0:04.826 | 1:53.336 | 3:34.584 | 0:02.681 | 5:30.473 | 1:41.592 | 1:50.339 | 1:49.615 Binaries Tests: | 1.6.17 | rNNNNNNNN | 0:00.062 | 0:00.035 | 0:00.030 | 0:00.031 | 0:00.030 | 0:00.037 | 0:00.029 | 0:00.030 | 0:00.029 | 0:00.027 | 0:00.026 | 0:00.030 | 0:00.031 | 0:00.028 | 0:00.030 And just to make the comparison easier, I've rerun the test with our repository on the same machine as the benchmark: svn 1.6.17 takes 5 minutes, svn 1.7.0 b3 takes 8 minutes for a complete checkout. The server's a Windows 2008R2 with collabnet's svn server 1.6.4. The client's also a Windows Server 2008R2. They're connected in a switched network, with a latency < 1ms. Our repository is open source, so, in case you believe it helps with benchmarking/finding the bottleneck, you're welcome to exporting the trunk (https://svn.re-motion.org/svn/Remotion/trunk/) and creating a new benchmark repository. Am I correct in my assumption that building a new repository based only on the latest revision of the trunk would result in similar performance figures given it appears to be a client related issue? Is there any additional information I can provide to help figuring this out? Btw: I noticed while copying the performance numbers that the switch performance is also greatly improved. That's awesome news! We have some projects that do lot's of branching but aren't pursuing git/hg yet. Regards, Michael
