Plastic Gluon in detail
A detailed explanation of the motivation and internals.
A detailed explanation of the motivation and internals.
Artists and programmers team up in game development but they don't use the same tools and processes. Version control is not an exception. Things that are great for programmers (like great branching and merging and distributed development) are irrelevant for artists. Simplicity and avoiding feature creep are what artists care about.
When we started the design of Gluon we focused on the following requirements:
One of the most relevant studio using Plastic shared this with us:
To create the best possible version control tool for artists we had to develop a new user interface but also an additional "checkin engine" to give them the freedom to checkin and update even when the entire workspace was out-of-sync.
The new UI is all about keeping things as simple as possible. It has a few key components:
We removed all the other additional features and options to keep users focused on what they're really interested.
Keep reading to learn more about the "checkin engine"...
All modern distributed version controls (git, mercurial, Plastic SCM) work on a "changeset|commit" basis instead of on a file-per-file basis as previous generations did.
While this change makes a lot of sense for developers, it introduces some restrictions for the game artist workflow.
"Changeset oriented" version control (the basis of DVCS) means the entire repository evolves "together". There is no such a thing like "download version 3 of foo.c and version 7 of bar.gif". No. Whether you're on changeset 8, globally, or 10 globally, but you don't select files one by one.
This is done to keep what we'll call "changeset coherency". Your workspace is synced with the repo all the time (excluding potential local changes pending to be checkedin and special configurations with cloaked files). This is extremely convenient for code because you minimize broken builds and you think on the project as a whole: you sync to a given changeset and you know the code will work as it did when you submitted it.
While this is extremely good for code, it is a big issue for the "artist workflow" described above. Let us explain why:
Suppose an artist is working on a given file with regular Plastic. He is working on, let's say, changeset 19 as explained below:
Now the artist might want to get some new files checked in by other artists on changeset 20 and 21 and he faces the first issue with "changeset coherency":
If he wants to get a newer version of a file, he'll need to update from changeset 19 to 21, potentially downloading hundreds of files and megabytes.
And while it makes sense for a programmer (you wouldn't download a source file without making sure all the others are there up-to-date to build) it is can be a pain for an artist.
This is precisely what the new versioning engine solves: it allows the creation of workspaces where files can be updated one by one, breaking "changeset coherency" and still being able to checkin.
Now it is possible to:
As explained above, now it is possible to update only parts of the workspace with new contents from the repo, even on a file per file basis.
So it will be possible to have a situation as follows:
and still be able to checkin "only" zombieweapon.3ds to the head of the working branch, without having to merge first as it would happen when working with source code (note that no files need merge, but in "changeset coherency mode" a merge would be needed from 21 to the working copy prior to checkin).
While the way of working on "artists workspaces" and "coder workspaces" will be different, they'll still be able to checkin to the same repositories. They'll use different workflows and GUIs, but the repos can be shared among the two, keeping total compatibility.
Artists workspaces introduce total freedom to version on a file per file basis, but introduce a restriction: merges can't happen in these workspaces unless they're converted to "regular ones" running a full update (syncing with a changeset instead of having a out-of-sync status).
Since most artists precisely want to avoid merging and all costs... we think this is not a big price to pay for the new great flexibility.