General questions to get us up and running

[DavidL]

Right, so I'm trying to wrap my head around this whole source control thing. I've read up on all the documentation, made a cloud repository and connected it with Gluon. I'll be using this with the Unreal Plugin. There are a few things that have not properly slotted into my brain though.

Premise: We have a rather lage game project in UE4 we've been working on through Dropbox, but that is starting to get bothersome to keep track of. The idea is that we both have a local copy of the latest editor build, and we would use the 5GB cloud to keep track of the parts we add to and change, as we really don't want to be uploading the whole 20+ GB. I will then put the few GB we'll actively be using into the repo. 

Is this a viable way to work? Others I have spoken to seems to think this should be fine, but please do advise If I've got this wrong.

I have run some learning tests before we muck up our main project (like we did last time I tried to source control):

First issue: The workspace and repository is working fine, the Plugin does the source control and it updates in Gluon just fine. However, when I check in the changes they don't show up in the cloud. As in 0.0 GB on the dashboard. The artist who tried to download the repository also got null. However, when he added a file from his side that shows up in my incoming changes. What gives?

I guess the main thing I'm asking here, is if I'm wanting to sync up some parts of two projects on different computers used Plastic SCM, how would I go about this?

I pulled it of in Git since it seemed to just work, but Git is not great for large binaries as far as my testing goes, so I'm hoping a simple workflow with Plastic SCM Gluon can serve out purposes. 

[Mikael Kalms]

I don't work at Codice, but I have used Plastic and other VCSes for some time. My advice:

---

Think of Plastic and Git as "file systems with history, and support for multiple parallel timelines". They provide you with four things that are valuable when working on an UE4 project, compared to when working via Dropbox:

• You get exact control of when files are uploaded/downloaded. No more "person X changed a file so I guess I'll wait a while and the latest version ought to show up on my machine as well".
• You get tools that help you work collaboratively with a set of files. There are locking mechanisms which prevent two people from working on the same file at the same time, there is a standard for how and when to do conflict resolution (when two people have worked on the same file, in the case of not having used locking), and there are strategies for how to merge several peoples' changes within text files.
• You get detailed history. If someone says 'the game is not working for me' and you know which exact version they are on, you too can jump back in time to that version on your machine and reproduce the problem without needing access to their machine.
• You get the ability to temporarily split (branch) the timeline for the set of files into multiple parallel timelines, work independently on these timelines, and decide later on when it's time to merge two timelines back into one; this enables you to easily collaborate with a colleague (or share your work across two machines) before you share your work with the entire team.

---

Plastic is the most useful when you use it to manage a set of files that are tightly dependent on each other. All source code - regardless of language, be it C++ / C# / Lua / ... - is of this kind. The *.uasset/*.umap files in an Unreal project are also of this kind, to an extent. Non-engine format assets (*.mb / *.blend / *.psd / *.png / *.fbx / *.wav / *.mp3 / ...) are usually not as tightly coupled. You would still benefit from using Plastic IMO, but the gain is less there.

 

Therefore, I recommend that if you do not have enough space to put all of your project, put only the Unreal project into Plastic. If you do not have enough space to put the entire Unreal project into Plastic, you are moving into some tricky territory ... yes, you can split the Unreal project so that some parts are in Plastic and some are in Dropbox, but you will need to pick a stable split. Moving parts back and forth between Plastic and Unreal will not help you conserve space, because of what's in the next paragraph.

 

Plastic is designed to retain the entire history for all files that it manages. This means that if you put an Unreal project into Plastic, and then continue to work on it, all the old revisions of *.uasset/*.umap files will continue to take up space within the Plastic repository. Every time you upload a modified version of a file, the size of the repository grows. There is currently no mechanism for erasing old revisions of files from Plastic's history. Erasing entire files will not erase their history, so that doesn't free up space either. This will eat into your 5GB, and the size of the repository will keep growing as you work on it. If your project size is currently, say, 1GB -- then you can probably continue to work on your project for another year until you hit the 5GB cap. Otherwise, you will hit it quicker. Once you hit that cap you will want to either A) start paying per-month for Plastic to retain more than 5GB, or B) move to something else - I guess back to Dropbox, since other version control options aren't free at that scale either - perhaps you could run your own Git server, on a machine of your own... with all the maintenance & backup woes associated?

 

Do not use Plastic to distribute packaged builds of the game. The history that Plastic provides is not worth the extra space. Continue to use Dropbox for those.

On our previous game, we kept our "source-format assets" in Google Drive, and the entire game project in a Plastic repository. For our current game, we keep our source-format assets in another Plastic repository, for the sake of convenience. We have ~500GB of files+history in Plastic Cloud today. We use a combination of Google Drive and Google Cloud Storage (+ a bunch of scripts) to distribute packaged game builds.

---

If you want Plastic to only manage some of the files in a folder structure, then you place a file named "ignore.conf" in the root of the Plastic workspace. You will see that Plastic's UI will hide stuff that you have ignored. Notice that this ignoring mechanism is protection from accidentally adding unwanted files to being managed by Plastic -- once you have added a file, Plastic will continue to manage it, regardless of what ignore.conf says. The ignore mechanism is useful if you want, for example, the entire Content folder to be managed by Dropbox, or you want to ignore a "Builds" folder where you typically put packaged builds on your machine. See docs here.

---

What you describe above -- create a repository in <your org@Cloud>, create a workspace on your machine that is linked to <your repository@your org@Cloud>, Configure your workspace in Gluon to include the entire root folder, perform some actions in your workspace, then clicking "check in" -- should be enough to make files upload to the repository. This should also result in an entry in the "Changesets" tab within Gluon. Your colleague should be able to see your changeset listed within "Changesets" too. Your colleague should be able to fetch your files by clicking "Update workspace", either in the "Explore workspace" or the "Incoming changes" tabs.

If something goes awry there then I typically use the full Plastic SCM client. It allows browsing the server-side history and see which actions have been performed with more detail.

I would advise that, once you have figured out how Gluon works, create a blank repository in cloud + clean workspace on one machine, copy over the entire project from Dropbox to the workspace folder, edit ignore.conf appropriately (ignore Binaries + Intermediate + DerivedDataCache + Saved folders) and check in the entire workspace from that machine. Then create workspaces (pointing to the same, now no-longer-blank repository) on the other machines. At that point, everybody has the same set of files on their machines, you are in sync -- you are now ready to start collaborating. Gluon's UI should guide you from that point onward.