On 09.01.2015 15:43, Branko Čibej wrote: > On 09.01.2015 14:04, Ulrich Stärk wrote: >> If I'm not mistaken, SVN does the same (combine and compress all changes >> prior to sending it over >> the wire). > Not entirely; it sends deltas and will compress new files IF the server > has mod_deflate configured (but they usually don't because there was a > huge memory leak there for the longest time), but doesn't combine them. > It can't, since it doesn't have the repository available locally. > Subversion working copy state can differ substantially from repository > state, yet the commit can still succeed; this is not the case with Git. > > On 2015-01-08 10:28, Robert Metzger wrote: >>> I think there is a performance difference between git and svn because with >>> git, you are syncing repositories, not files. Git is usually compressing >>> the repository before sending it over the network. >>> I did a little test with our website directory and pushed it to github: >>> >>> git add : 7 seconds (17k files) >>> git repo size: 58 MB (du -sh in ".git" dir) >>> git push to github : 35 seconds (using the same internet connection as with >>> the svn) > In this case, Subversion will generate a PUT request for each file, > whereas Git will, IIRC, send a single file across the wire. The problem > here is that Subversion does not (yet) pipeline PUTs, so the difference > you're seeing is the request latency. > > We've been talking about pipelining PUTs for ages ... but no-one is > currently working on that, so ... we need more incentive! :)
FWIW, such commits should be a lot faster via svn:// than via http://. But we can't use svn:// at all at the ASF because the repo replication method we currently use only supports http://. -- Brane
