9

Our team decided that is time to finally leave Serena PVCS behind ( yay!! ) and now we have to decide between git or SVN. But even after reading some outdated docs and posts regarding how git handle bin files i couldn't find a direct answer about this topic. So, since one of our repo's have 50gb, and 90% of then are .doc, .xls, .zip ( each one from 1mb to 20mb from version 1.0 to 1.178), i'm not secure to turn my boat to the Git Island.

what i found so far is:

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" ( recent born developers with less than 1y out of the university ) are crying out for git because is "mainstream" but i dont think git would solve the problem this type of repo. I mean, we allready manage some repos using git ( for java source mainly ) but i'm struggling to decided for which direction should we aim.

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

Thanks in advance.

EDIT: Please understand that i'm not going into "gorila vs shark" philosophy , i'm just trying to get more inputs in order to decide if i should choose git over svn.

Improve this question
1
  • 1
    From a personal PoV (that's why it's not an answer), Git wins mostly for me because you can work locally and easily merge your changes with the master, most of the time automatically. However, considering the fact that you can't merge changes of two, say, .zip files, and keeping them locally would inflate local copies, I'd probably go for SVN. Saving yourself the trouble of all that git extensions targetted at binaries would be another plus for me. Commented May 8, 2014 at 11:57

3 Answers 3

Reset to default
9

most of our "geeks"

are not geeks, but brainless Git-fanboys. Ignore juniors totally, they must not have voice

From personal experience I can conclude that both systems handle big binaries almost equally mediocre with with a slight advantage from SVN (for pre-1.7 versions, now I don't see at Git side at all):

  • the same modified file, committed to repository, increased the size of the SVN repository slightly smaller than Git-repository
  • I never had broken SVN-repo with big files, with Git it happened noticeable amount of time

For your case best choice will be Mercurial with LargeFiles extensions (and special differs|mergers|viewers per file-types, encoders|decoders are additional bonuses, which Git|SVN can't offer)

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Im adding your answer as right, since it helped me to decided for mercurial. And i found this post, must read :) ericsink.com/entries/hg_denzel.html
5

Git doesn't work that well with binaries, since it doesn't compress them that well. They'll end up taking a massive amount of space in your Git repo history. I had first-hand experience with this; when I added and removed a couple of small pictures, it took ages for me to reclone the repository.

For SVN, since it's centralised, it doesn't really affect developers as you don't need the whole history of the repository anyway (in most cases). As for space taken up on the server, I am not too certain about that.

It would be best to seek an alternative method to upload large binaries. Perhaps the best way would be to upload the files to an alternative source. SVN should be fine with binaries. As for Git, don't ever use it with binaries. If you must, keep the binaries in a seperate repository.

But since you don't, you should probably use SVN.

Links for further reading:

Git and binary data

Improve this answer

1 Comment

I found the linked post very useful. Git is optimized to store source code text.
0

You could use git-lfs (Git Large File Storage) for this.

From the git-lfs page linked above:

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

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.