I wish that game dev peeps would see that Git for large graphics files is a real problem.

No, LFS does not help you.

Every change to your 2gb blender file is an ENTIRELY NEW FILE.

Am I wrong?

It seems we badly need a git for design/binary files that does not multiply megabytes.

#dev #gamedev #git

@dbat According to this two year old r/blender comment, Subversion can do it, as long as you don't compress the file https://www.reddit.com/r/blender/comments/1bvi833/comment/kxzn4bo/
@clayote I've long heard of the ancient subversion gods. Do they still live?
@dbat "What is it that takes 2GB?" would be *my* first question.
@code_disaster Graphic design files can multiply alarmingly, and there's never just one blend, or png, or video file...
@dbat the same issue exists in the research data management world with #DataLad / #gitAnnex. One thing that I am doing for our storage servers is regularly run #duperemove on it. It requires filesystem support (xfs/btrfs), but deduplicates on an extent basis, so below the file level. If the difference between two versions only affects a small part of a file it should be able to help. I wonder if it could be run as a post-commit hook, or something like that.
@matrss this is a great comment, full of promise and ideas. Most of it is over my head, but I'd be glad to hear how it goes.
@dbat version control of binary blobs is a difficult problem
blender, specifically, should probably have a way to save deltas
some day...

@efi being a bit stupid, i can't quite see why blobs should be hard to diff.

I also keep thinking of parity files (par2) from usenet days and how one could fix holes in bad downloads. It was kind of magic.

@dbat it depends on how the blob is made! there's a bindiff tool you can use to see it for yourself, but it's usually not very pretty =3
@efi I'll have a go at bindiff just to learn a bit. Tanks!
@dbat apparently there's a visual tool for it, vbindiff