Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is git worth for managing many files bigger than 500MB

I would put under version control a big amount of data, i.e. a directory structure (with depth<=5) with hundreds files with size about 500Mb).

The things I need is a system that help me: - to detect if an files has been changed - to detect if files were added/removed - to clone the entire repository in another location - to store a "checkpoint" and restore it later

I don't need sha1 for change detect, something faster is acceptable.

Is git worth for this? There is a better alternative?

like image 804
Andrea Francia Avatar asked Nov 19 '09 10:11

Andrea Francia


People also ask

What file size is too big for Git?

File size limits GitHub limits the size of files allowed in repositories. If you attempt to add or update a file that is larger than 50 MB, you will receive a warning from Git.

How many files can Git handle?

There is no real limit -- everything is named with a 160-bit name. The size of the file must be representable in a 64 bit number so no real limit there either. There is a practical limit, though. I have a repository that's ~8GB with >880,000 files and git gc takes a while.

Does GitHub have a storage limit?

GitHub limits Only the 100 MB threshold is blocked and this is the GitHub file size limit. If you are uploading via browser, the limit is even lower – the file can be no larger than 25 MB. Of course, these are the default settings, but you can extend these limits and add larger files to the repo.

How much data can I upload to GitHub?

GitHub has a strict file limit of 100MB. If you are just uploading lines of codes, this is not something that you need to worry about. However, if you want to upload a bit of data, or something in binary, this is a limit that you might want to cross.


2 Answers

As I mentioned in "What are the Git limits", Git is not made to manage big files (or big binary files for that matter).

Git would be needed if you needed to:

  • know what has actually changed within a file. But for the directory-level, the other answers are better (Unison or rsynch)
  • keep a close proximity (i.e. "same referential") between your development data, and those large resources. Having only one referential would help, but then you would need a fork of Git, like git-bigfiles to efficiently manage them.

Note: still using Git, you can try this approach

Unfortunately, rsync isn't really perfect for our purposes either.

  • First of all, it isn't really a version control system. If you want to store multiple revisions of the file, you have to make multiple copies, which is wasteful, or xdelta them, which is tedious (and potentially slow to reassemble, and makes it hard to prune intermediate versions), or check them into git, which will still melt down because your files are too big.
  • Plus rsync really can't handle file renames properly - at all.

Okay, what about another idea: let's split the file into chunks, and check each of those blocks into git separately.
Then git's delta compression won't have too much to chew on at a time, and we only have to send modified blocks...

Based on gzip --rsyncable, with a POC available in this Git repo.

like image 77
VonC Avatar answered Nov 15 '22 18:11

VonC


git-annex is a solution to this problem. Rather than storing the large file data directly in git, it stores it in a key/value store. Symlinks to the keys are then checked into git as a proxy for the actual large files.

http://git-annex.branchable.com

like image 22
Joey Avatar answered Nov 15 '22 20:11

Joey