Abuse of version control

Question

Is version control suited for a project where content is essentially binary data files ? I am thinking about package that weight something like 10 giga, with a lot of BMP and TGA files.

Can subversion handle something like this ? Is it possible to generate some kind of binary patch that would allow users to download only what was modified. Rsync could be an option, but then there is no going back. I would really like to be able to go back to an earlier version easily.

I looked at this question too, but was not satisfied with the answer

Answer 1

You issue is a release management one which includes:

• building: how and how fast are you able to regenerate some or all of the delivery content ?
• packaging: how many files are present in that delivery ?
  if your content includes too many files, it will simply not be easy to deploy (i.e. copy or rsync) in any remote environment, not so much because of the global size, but because of the number of transactions needed.
• publishing: where do you store your delivery and how to you link it to the initial development environment that produced it ?

I would argue that such a massive delivery is not made to be published in a VCS, but rather store in a filesystem-based repository, with a proper name (or version.txt) to be able to identify its version and link it back to the development content (stored and tagged in subversion).
Maven is an example of such a repo.

I would also point out a content made to be delivered should include a limited number of files, which means:

• compressed lots of related files together into one compressed file
• run a script which does not just rsynch, but also un-compressed those files

Answer 2

Subversion uses xdelta for binary files.

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

BTW. related question: How good is Subversion at storing lots of binary files?