community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Managing (was RE: WELCOME to
Date Fri, 09 Jan 2015 14:43:30 GMT
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! :)

-- Brane

View raw message