So I ended up writing my own Git LFS implementation that integrates into ThriveDevCenter, another thing I’ve been working on every now and then:
https://dev.revolutionarygamesstudio.com/lfs
In my own tests it seems to work well. It also seems to work well with circleci and appveyor. But I’d like to have some people (cough @GatoCreador887 cough) test if the windows git lfs installation instructions work: https://leviathanengine.com/doc/develop/Documentation/html/dc/d9e/prerequisites.html
and if the latest commits on Leviathan develop branch compile and run fine (LeviathanEditor.exe).
You can see how gloriously only text files are stored in git itself (and the big files are in git lfs) here: https://github.com/hhyyrylainen/Leviathan/tree/develop/Assets/Fonts/Simonetta
I didn’t do anything to Thrive itself yet as I’d like some testing done before that. But with this we will finally get a way for everyone on the team to make asset changes and also we can update assets without worrying that master breaks.
So my plan is that once Leviathan is tested to work fine with git lfs, I’ll move the thrive assets from svn to two Git LFS places: Thrive Assets will contain all the files that the game need to run correctly (including the GUI textures), and Thrive Raw Assets will contain the “source” files for the assets (all the texture images and editable models), this way the amount of needed space is reduced when not wanting to work on the assets. For this I’ll need to create a new Git repo called Thrive-Raw-Assets on github. But I’ll setup the asset import script to clone that automatically, so everything will be smooth.
Once I do the conversion everyone will need to delete their assets folder otherwise things will probably break. But this needs to only be done once, so this isn’t too out of the ordinary for requiring deleting stuff in the thrive folder to get things working again.
For now the artists would need to install git + git lfs if they want to get the raw files. Maybe in the future I’ll make a file browser on ThriveDevCenter to download individual assets that way.
I wrote a wiki page about how to get write access to git lfs:
I didn’t implement the lfs file locking API so that can’t be used before it is done, it shouldn’t be too big of a problem. Also I might have gone a bit overboard with futureproofing the Git LFS module. It uses Wasabi for storing the files, which means that the storage space is basically infinite (as long as I can afford paying 5$ per month per terabyte of data). And that’s not all, it uses a content delivery network (BunnyCDN) to deliver the files to whoever is downloading them. So the downloads should stay super fast no matter how many people are downloading them at once (this costs me a bit over 6$ per terabyte of data). As I said this may be a bit overboard for our current use, but at least we won’t be bottle necked in the future. I’ll probably use the same approach for hosting dev builds once I get per-commit dev builds setup, those will be taking a bunch more traffic, at least if we can get some more monetary supporters.