Git vs SVN With Non Text Files / Large Projects

Question

I have been learning Git the past weeks or so and I really like the way it works in comparison to SVN. The main reason I am looking to fully switch to it is the fact that merging is supposedly a lot easier with few conflicts and the fact I can commit locally. This promotes the use of many branches (like a branch per ticket/issue/task/etc..) and also promote many commits. I only use branches if I need to in SVN (since merges often produces conflicts) and I only commit when I am 100% sure the issue is fix (instead of incremental commits, which would be nicer).

Now, one concern I have about git as I have been reading it is about non text files/large projects. For example I am working on a game project currently controlled in SVN. Now with a game project, there are going to be a lot of non text files like art, sound, and other binary files and some of the files can get pretty big. How well does git handle non text file / large binary files? What are some of the considerations I have to keep in mind if I want to port over such a project to git?

Answer 1

One of the big differences in how Git stores data compared to other version control systems is that Git stores the file content completely as a single object. That means that every version of every file exists as a complete file in your repository (it's very compressed though). So while other VCS store the differences/deltas between two versions, and as such handles binary and text files differently (as binary files are not that diff-able), Git just handles all of them identical.

As such, working with binary files in Git is not different to using any other file type. You just need to keep in mind that versioning very large files is going to increase your repository size a lot (as every single version of that large file is stored as it is, even if the actual, binary change was small). Git's compression however works wonders and makes you not notice this usually. Especially if you are only talking about a program's assets, you probably won't have any difficulties.

Answer 2

Adding @poke's answer

I am an avid Git user these days, but having worked in a huge project where there were lots of binary files - mostly zips - to be handled - I found SVN to be more efficient than Git. The size of the Git repo got bloated up in no time while the size of a similar SVN repository did not vary much. Cloning such a huge Git repo, especially across geographically distributed places was a nightmare. Git also doesn't have a partial clone feature, something that we do in SVN all the time - checkout just a particular folder. There is partial checkout in git, but you still have to clone the entire repo.

Note that whether or not a file is binary does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files; this is completely unrelated to the diffing method used by the 'svn diff' command.

http://subversion.apache.org/faq.html#binary-files

Given SVN's mature sys admin tools ( Git also has improved over the years, but I feel SVN still has the edge in this aspect ) I think it will be wise to have a SVN server with probably git-svn repo for local development.

There is something call git-bigfiles - which is a fork of git. Not sure how mature it is. You can evaluvate it. But the fact that it exists, shows Git is not necessarily good at handling large files.