If you are happy to just use the features from Gluon (so you will not do any branching/merging) then you can put all your stuff into a single repo, just like you speculate at the beginning.
We made a turn-based strategy game in Unity. We really wanted to use task branches for the Unity project itself, but were concerned about repo size & workspace size, just like you. For that project, we kept all source assets in Google Drive, and the Unity project in Plastic. We used the full Plastic SCM client (not Gluon).
Google Drive provided a simple way of sharing files. It provided a backup in case of catastrophic disk failure.
The Plastic repo ended up at 85GB including history.
Overall, this worked well for us. The main problems when using Google Drive for source assets are, 1) it is not obvious to users when synchronization is complete, and 2) it is cumbersome to look at history, 3) there is no linkage between "source asset version X" and "imported asset version X".
We are now making larger FPS in Unreal. We still want to use task branches for the Unreal project. Our source asset collection is so large that if we were to put it in Plastic, we don't want to fetch all of it when getting latest. For this project, we keep all source assets in one Plastic repo, and the Unreal project in another repo. We use Gluon (with partial checkout) for the former repo, and Plastic SCM (using branches) for the latter repo.
The source assets repo is currently at 650GB including history. A full checkout would be >100GB, but no-one does that.
The Unreal project repo is currently at 300GB including history. A checkout is ~25GB.
Overall, this works well for us. The main problem when using two separate repos are, there is no linkage between "source asset version X" and "imported asset version X", other than looking at timestamps. It does not cause us much trouble in practice.
We are evaluating the Dynamic Workspaces feature. In the future, it may allow us to combine both repos into one, while still allowing us to use branch-based workflows, yet only requiring people to download the files that they access. It is not flexible enough for us yet; we need it to work on multiple OSes and possibly in Docker containers to satisfy our build system needs.
so you separate the artist repo and program repo , the artist uses the gluon and programmer use the plastic, the artist repo without any code. did I understand right? thank you.
Recommended workflow / project structure for project with code & art
in General
Posted
so you separate the artist repo and program repo , the artist uses the gluon and programmer use the plastic, the artist repo without any code. did I understand right? thank you.