| Follow @monsterjavaguns
Atlanta, GA
Jason van Gumster mostly makes stuff up. He writes, animates, and occasionally teaches, all using open source tools. He's run a small, independent animation studio, wrote Blender For Dummies and GIMP Bible, and continues to blurt out his experiences during a [sometimes] weekly podcast, the Open Source Creative Podcast. Adventures (and lies) at @monsterjavaguns.
Authored Comments
Took a bit of research, but it turns out that I was mistaken. Large files *are* versioned... the revisions are just stored separately. I get that now. When you do a checkout, you get only the files that you need for that revision/branch. However, if you're doing ad-hoc versioning without a central server (that is, versioning a project in place and not necessarily sharing/collaborating with anyone), that could be a bit troublesome to set up... maybe. I guess there's only one way to know for sure. :)
The difficulty I have with any of the large file support schemes is that (as far as I can tell), you're not actually versioning any of your assets. Sure, you have large files and you have a log of the changes you've made, but unless I'm misunderstanding something fundamental, there's no mechanism for rolling back those large binary files to previous versions. That's a dealbreaker for me since the ability to branch and roll back are my two primary reasons for using versioning.
In short, please tell me I'm wrong. Does Git LFS, git-media, or git-annex support branching and rolling back large binary files and the documentation is just really obtuse? Or have I, sadly, read the documentation correctly?