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?
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.
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.
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.
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.
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:
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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With