From my own experience, the following statements are all true:

• Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git.
• This is completely wrong if you compare the size of repositories were a significant amount of files are office files (like MS word, excel, powerpoint, ...). Here Git stores complete copies as well, which means that 10 small changes on a powerpoint slide stack results in 10 complete copies, where Subversion only stores a binary diff, which may be a factor of 100 smaller.

If you compare the checkout location (which is a repository in itself with Git), the story is totally different:

• Subversion stores for each file a complete copy, so the size of your checkout location is normally 2 times the size of the files themselves.
• Git stores the complete history of the repository locally, so depending on the size of the history, this may be smaller or much bigger than that of the Subversion checkout copy.

If you compare the amount of bytes you have to down- or upload, it is different again.

• Subversion has normally to send or receive less bytes, because it only sends differences. It has to do that on every commit and update.
• Git has to get the whole repository (initially), and then sends complete files (compressed?) which is not such different for text files, but may be different for binary files. And yes, Git only does that when you push or pull something to the remote repository.

So at the end, you compare apples with oranges, and depending on what you want to do with Subversion or Git, the result may be different.

@jk asked about complete copies or binary diffs, and I could not answer that question. I asked Matthew McCullough which gave a Git workshop lately at Jax 2012 (which I visited). He has taken the time (thank's a lot to him) to explain with a detailed gist the inner working of Git. So yes, there is a compression working there (and I will do an experiment with a microsoft office file as well and will compare that with his gist), but not, the compression is done on the whole file. Citing from his gist:

Loose objects are written in compressed, but non-delta format at the time of each commit.

From my own experience, the following statements are all true:

• Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git.
• This is completely wrong if you compare the size of repositories where a significant amount of files are office files (like MS word, excel, powerpoint, ...). Here Git stores complete copies as well, which means that 10 small changes on a powerpoint slide stack results in 10 complete copies, where Subversion only stores a binary diff, which may be a factor of 100 smaller.

If you compare the checkout location (which is a repository in itself with Git), the story is totally different:

• Subversion stores for each file a complete copy, so the size of your checkout location is normally 2 times the size of the files themselves.
• Git stores the complete history of the repository locally, so depending on the size of the history, this may be smaller or much bigger than that of the Subversion checkout copy.

If you compare the amount of bytes you have to down- or upload, it is different again.

• Subversion has normally to send or receive less bytes, because it only sends differences. It has to do that on every commit and update.
• Git has to get the whole repository (initially), and then sends complete files (compressed?) which is not such different for text files, but may be different for binary files. And yes, Git only does that when you push or pull something to the remote repository.

So at the end, you compare apples with oranges, and depending on what you want to do with Subversion or Git, the result may be different.

@jk asked about complete copies or binary diffs, and I could not answer that question. I asked Matthew McCullough which gave a Git workshop lately at Jax 2012 (which I visited). He has taken the time (thank's a lot to him) to explain with a detailed gist the inner working of Git. So yes, there is a compression working there (and I will do an experiment with a microsoft office file as well and will compare that with his gist), but no, the compression is done on the whole file. Citing from his gist:

Loose objects are written in compressed, but non-delta format at the time of each commit.

From my own experience, the following statements are all true:

• Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git.
• This is completely wrong if you compare the size of repositories were a significant amount of files are office files (like MS word, excel, powerpoint, ...). Here Git stores complete copies as well, which means that 10 small changes on a powerpoint slide stack results in 10 complete copies, where Subversion only stores a binary diff, which may be a factor of 100 smaller.

If you compare the checkout location (which is a repository in itself with Git), the story is totally different:

• Subversion stores for each file a complete copy, so the size of your checkout location is normally 2 times the size of the files themselves.
• Git stores the complete history of the repository locally, so depending on the size of the history, this may be smaller or much bigger than that of the Subversion checkout copy.

If you compare the amount of bytes you have to down- or upload, it is different again.

• Subversion has normally to send or receive less bytes, because it only sends differences. It has to do that on every commit and update.
• Git has to get the whole repository (initially), and then sends complete files (compressed?) which is not such different for text files, but may be different for binary files. And yes, Git only does that when you push or pull something to the remote repository.

So at the end, you compare apples with oranges, and depending on what you want to do with Subversion or Git, the result may be different.

From my own experience, the following statements are all true:

• Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git.
• This is completely wrong if you compare the size of repositories were a significant amount of files are office files (like MS word, excel, powerpoint, ...). Here Git stores complete copies as well, which means that 10 small changes on a powerpoint slide stack results in 10 complete copies, where Subversion only stores a binary diff, which may be a factor of 100 smaller.

If you compare the checkout location (which is a repository in itself with Git), the story is totally different:

• Subversion stores for each file a complete copy, so the size of your checkout location is normally 2 times the size of the files themselves.
• Git stores the complete history of the repository locally, so depending on the size of the history, this may be smaller or much bigger than that of the Subversion checkout copy.

If you compare the amount of bytes you have to down- or upload, it is different again.

• Subversion has normally to send or receive less bytes, because it only sends differences. It has to do that on every commit and update.
• Git has to get the whole repository (initially), and then sends complete files (compressed?) which is not such different for text files, but may be different for binary files. And yes, Git only does that when you push or pull something to the remote repository.

So at the end, you compare apples with oranges, and depending on what you want to do with Subversion or Git, the result may be different.

@jk asked about complete copies or binary diffs, and I could not answer that question. I asked Matthew McCullough which gave a Git workshop lately at Jax 2012 (which I visited). He has taken the time (thank's a lot to him) to explain with a detailed gist the inner working of Git. So yes, there is a compression working there (and I will do an experiment with a microsoft office file as well and will compare that with his gist), but not, the compression is done on the whole file. Citing from his gist:

Loose objects are written in compressed, but non-delta format at the time of each commit.