Johan Corveleyn <jcor...@gmail.com> writes: > As I said in my previous response here, I think the reason for Paul to > go for curl+autoversioning is speed, because it eliminates client-side > deltification. It was suggested and demonstrated by Philip here:
Using a trunk build, I'm uploading 500MB urandom files: dd if=/dev/urandom bs=1M count=500 > u1.dat dd if=/dev/urandom bs=1M count=500 > u2.dat dd if=/dev/urandom bs=1M count=500 > u3.dat using curl -T u1.dat http://localhost/repo/curl.dat curl -T u2.dat http://localhost/repo/curl.dat curl -T u3.dat http://localhost/repo/curl.dat and svnmucc -mm put u1.dat http://localhost/repo/svn.dat svnmucc -mm put u2.dat http://localhost/repo/svn.dat svnmucc -mm put u3.dat http://localhost/repo/svn.dat to a repository with compression-level=0 and enable-rep-sharing=false. The upload that creates the file is faster than the upload that updates the file: curl create time: 4.2s curl update time: 6.7s curl CPU in both cases: 0.2s svnmucc create time: 5.2s svnmucc update time: 7.7s svnmucc CPU in both cases: 1.2s The difference between curl and svnmucc matches the extra CPU used by svnmucc. The difference between create and replace is due to the extra server CPU httpd CPU create: 3.0s httpd CPU replace: 5.5s The fact that the create is faster than the update means that if uploading the data is the only thing that matters then breaking the history and changing the update into a delete+recreate is faster, i.e. svnmucc -mm -U http://localhost/repo put u1.dat svn.dat svnmucc -mm -U http://localhost/repo rm svn.dat put u2.dat svn.dat svnmucc -mm -U http://localhost/repo rm svn.dat put u3.dat svn.dat The delete+recreate takes the same 5.2s as the original create and is faster than curl's 6.7s update. -- Philip
