1. Film sets contain wild walls that can be easily removed to accommodate light and camera placement outside the space looking inwards. Wild walls in the dioramas could have prevented the necessity of cutting holes.
2. Git is not the right SCM for the job. My first choice would have been Plastic a few years ago, but this got rolled into Unity DevOps after an acquisition. But it is meant to accommodate truly vast repositories (53GB isn't actually that big). The second best choice is SVN - yes, really.
With LFS handling assets with Git shouldn't be a problem. From the sounds of it, the biggest problem they had here was not in the technology but GitLabs pricing which doesn't separate LFS storage. For example GitHub and BitBucket have separate pricing for LFS, both at more reasonable $.1/GB, i.e. five times cheaper than GitLab. If I'm reading it right Azure even offers LFS for free(!).
Technically I believe you can even have LFS hosted in different place than the repo itself, although I don't know if these commercial providers handle such case. But in theory you could host your git repo at gitlab.com and selfhost lfs if you want to penny pinch.
The one standout quality that git LFS has in my experience is the rate at which working copies with LFS enabled shred themselves and become unrecoverable. I've seen this on multiple projects and different users now and it doesn't give me the confidence I'd need to rely on it for a big project.
I'm sure that there will be people replying that this is anecdotal etc. But this is my personal experience and what shapes my recommendations.
I've been using it for many years now for data repos like photos. IIUC one advantage it has over LFS is its model makes it easier to store data in many different places (though I don't use LFS myself).
Yes, SVN handles large amounts of big binary rather efficiently. It employs some binary diffing internally to keep storage usage low.
The centralized model also allows optional file locking, which reduces the risk of accidental merges destroying a file. This is a major concern for files that aren't source code when no dedicated merge tool exists.
Also, the centralized storage of the repo history becomes a bit of a bonus at this scale as it doesn't need to be replicated to each client, saving a little bit on disk storage and data transfers.
The one unfortunate downside of SVN is the implementation of merging between branches. That relies on per-file merge histories that are partially stored in per-file properties. This is opaque, internal information, yet it is tracked the same way as file changes. This leads to situations where it's all too easy to discard some of the merge history with harmless looking operations like reverting a file between a local merge and its merge commit to get rid of an unwanted change. Once something like this happens, future merges end up doing random looking things like re-applying changes that have already been merged. This is a major part of what gives SVN its bad reputation. You really have to tread on eggshells when merging. If you can avoid the pitfalls, merging works well. But it requires rather deep knowledge of SVN and discipline.
Yeah, this plus the apparent lack-of-planning regarding lenses & field of view make me wonder if OP had any of the background they should have had in stop-motion animation?
This is the sort of project that, no matter how much you know, or think you know, and no matter how much experience you had, it'll still bring you right back down to Earth and humble you somehow. There is no curriculum for preparing for this. There is only "jump in and figure it out as you go".
So let's not criticize anyone for jumping in and figuring it out as they go, as it is the only way to produce a project like this.
1. Film sets contain wild walls that can be easily removed to accommodate light and camera placement outside the space looking inwards. Wild walls in the dioramas could have prevented the necessity of cutting holes.
2. Git is not the right SCM for the job. My first choice would have been Plastic a few years ago, but this got rolled into Unity DevOps after an acquisition. But it is meant to accommodate truly vast repositories (53GB isn't actually that big). The second best choice is SVN - yes, really.