How Git or SVN handle large binary files

Our team decided it was time to finally leave Serena PVCS (yay !!) behind, and now we have to choose between git or SVN. But even after reading some outdated documents and messages about how git handles bin files, I could not find a direct answer on this topic. So, since one of our repos has 50 GB, and 90% of them are .doc, .xls, .zip (each from 1 MB to 20 MB from version 1.0 to 1.178), I'm not sure I can turn my boat in git island.

what i found is this:

https://help.github.com/articles/working-with-large-files

http://stevehanov.ca/blog/index.php?id=50

https://news.ycombinator.com/item?id=3548824

Most of our "geeks" (recently born developers with less than 1 year from the university) require Git because it is "core", but I don't think Git will solve the problem of this type of repo. I mean, we already manage some repositories using git (mainly for the java source), but I'm struggling to decide which direction we should go.

Also, besides Git / svn / Mercurial, is there any other option for bin files?

Thank you in advance.

UPDATE: Please understand that I am not going to the “burn against sharks” philosophy , I am just trying to get more information to decide if I should choose git instead of svn.

+8
source share
3 answers

most of our "geeks"

are not geeks, but brainless git-fanboys. Ignore juniors completely, they should not have a voice

From personal experience, I can conclude that both systems process large binary files, almost equally mediocre with the small advantage of SVN (for versions up to version 1.7, now I don’t see on the Git side at all):

  • the same modified file attached to the repository increased the size of the SVN repository slightly less than the Git-repository
  • I never violated an SVN repo with large files, and Git took a noticeable amount of time

For your case, the best choice would be Mercurial with LargeFiles extensions (and special differences | merges | viewers on file types, encoders | decoders - additional bonuses that Git | SVN cannot offer)

+9
source

Git does not work well with binary files, since it does not compress them so well. They will eventually take up a huge amount of space in your Git repo history. I had first-hand experience; when I added and deleted a couple of small snapshots, it took me a long time to set aside the repository.

For SVN, since it is centralized, this does not affect developers, since you do not need the entire repository history in any case (in most cases). As for the space occupied on the server, I am not too sure about this.

It is best to look for an alternative method for downloading large binary files. Perhaps the best way is to upload files to an alternative source. SVN should be ok with binary files. As for Git, don't ever use binary files. If necessary, save the binaries in a separate repository.

But since you do not, you must use SVN .


Links for further reading:

Git and binary data

+4
source

For this purpose, there is a new open source git extension called git-lfs (Git large file storage) .

git-lfs developed and maintained by github.

From the git-lfs page referenced above:

Git Large File Storage (LFS) replaces large files, such as audio samples, videos, datasets and graphics, with text pointers inside Git, storing the contents of the file on a remote server ...

0
source

All Articles