Gluon can now merge – a story of version control for games
I love telling stories, so today besides making a few announcements, I'm going to share how we see version control working for games, and how our vision evolved by working side-by-side with studios.
Announcement first: Plastic Gluon, the UI and workflow designed for artists in game development, can now merge files.
We released it last week as part of 7.0.16.2256 and it is a major change in the Gluon feature set.
Like every story in software development, I'm going to share what we tried first, and how our vision and understanding was shaped by constant user interaction.
I will explain the why's of this decision and how it fits into our overall version control strategy for game development.
The original spirit of Gluon
When we started working on Gluon, a few years ago, we had three key requirements from Telltale:
- As a user, I will select the files that I will work on, makes changes to and easily submit them. I don't ever want to deal with merging or branching files either. Those functions should happen automatically in the background.
- As a user, I want to lock files so that nobody can work on them at the same time as me.
- As a user, I don't want to be forced to download a file repository containing tons of huge files just so I can access the one or two files that I need to work on. I should be able to select only the files I want to work on and download those.
It is number 1, the I don't want to deal with merging or branching part, that has been modified.
First, we added the capability to switch branches in Gluon recently, and now it can also merge files.
Shouldn't it be simpler?
The many roles in game teams
Typically, we find this structure in game projects:
- An art data repo: Normally a huge one with tons of huge files in their original form. The Maya's, 3D Studios, Photoshops and Sketchs of the world go here. Artists with great design skills but little love for version control nerdery work here.
- The assets repo: Converted content from the art data ready to be used by the game. Everyone in the team uses it to test, develop and debug. It is way smaller than "art data".
- A third repo with game code: Teams with their own home-made game engine typically have another repo for it. More on this here.
Well, three different kinds of repos, but also different roles involved: artists, coders but also game designers, to mention a few.
We tried the "one tool to rule them all" but it didn't work and that's why Gluon was born in the first place.
But, the assumption of a binary split of "people who merge" using regular Plastic, versus "people who don't" using Gluon, was a little bit short-sighted. Why? Because people like "game designers" prefer to work in Gluon mode (single branch, simpler UI without the version control nerdery) but... want to merge!
Yep, they touch text files (scripts, behaviors, definitions) that can be merged easily, and worked on in parallel. They don't need the "lock-edit-checkin" workflow of the artists.
Also, we found teams where even coders also like to use Gluon due to its simpler UI. Less actions, less onboarding for newcomers, less barriers for users who are not branchaholics. They need to merge, though.
Merge without merge-tracking for single branch only
What is the typical scenario for Gluon merge? Very simple:
- You are working on main, and touch DogBehavior.cs.
- Meanwhile Pat touched and checkedin DogBehavior.cs too.
- Now you want to checkin and... bang! Merge needed.
This was end of the trip in Gluon world, because we designed it to work in "lock-only" mode. A little bit short-sighted on our side, but this is what it is. You would see a message saying: you have changes on a file that was changed by someone else, please undo your changes to checkin.
It made a lot of sense for binaries (no way to merge) but not for text.
What would users have to do if they still wanted to merge? Switch to regular Plastic, update (you need to convert gluon-mode workspaces into regular Plastic ones (partial to full workspaces in our jargon)) and then merge. Painful and error prone because this switch was not something we expected to happen often.
Even if you completed the merge in developer-Plastic-land, you ended up with potentially confusing situations for merge newbies:
You can't imagine how many developers are confused by the Car.prefab and friends being checked out in their workspaces after a merge. "I didn't touch the prefabs, why did they show up in merge!?" – they yell.
We needed that to preserve our merge tracking (which is a matter of honor for us :P), but many times, while working on the same branch, it just ends up being confusing for most users.
Merge in Gluon doesn't keep merge tracking, doesn't set merge links, so the Branch Explorer looks plain. The merge is correct, changes are correctly merged, but the merge-tracking metadata is skipped (in a great part because you need to be fully updated to a changeset to correctly set links, and this is something Gluon doesn't enforce, by design).
In short, we are making the lives much easier for game teams that deal with occasional merges in single branch development.
Merge without merge links in a single branch coming to regular Plastic
If you check my blogpost about our backlog you'll find a feature inside the "games" group saying "per-file merge single branch".
This is about implementing the same "merge-tracking-less" merges we just introduced in Gluon into regular Plastic.
This first made us cry "sacrilege!" as version control geeks, but after an exercise of putting ourselves into the shoes of the customers who work in a single branch, it made a lot of sense.
Why should you keep a complex branch history when a linear one is all you care about? Why not just merge what changed but avoid the links and just update your workspace to the latest as we do when there are no conflicts?
It makes perfect sense now and it is something we expect to deliver in the coming weeks.
What's up with branches?
Hey, no confusion here; we think branching, and task branches, are the way to go, for almost any project.
But, we want to be friendlier to newcomers and help them during the transition phase. Single branch development is not what we love, but we understand it is the simplest of simplest ways of working and the de-facto approach for many teams.
Our mission is to help them evolve to the next level, but instead of forcing them to become branch wizards from day one, we chose to help them in their trip instead.
Change in locking strategy
If you carefully read the release notes for 7.0.16.2256 you'll find another major change. Now when you merge, the "copied files" (files you changed in the source of the merge but are not in conflict) are not locked anymore.
Too technical? Skip reading.
Still here? Well, we changed this in early 7.0, but this small change made many users cringe when working on branches where part of the team was doing locking while others were working with mergeable files.
Here is why:
You modify CarBehavior.cs.
Later, someone else in the team makes some changes to a bunch of prefabs (binaries).
And a team mate checkins CarBehavior.cs too.
Later someone else locks again (checkout exclusively, but no checkin yet) Car.prefab.
And now you want to checkin your CarBehavior.cs. You are on regular Plastic, so you can merge normally even before BL2256.
Well, what happened? Plastic detected the merge and asked you to solve the conflicts in CarBehavior.cs. But, during the process, it has to download the 3 prefabs modified by another user into your workspace.
And here is where the issue happened: the strategy we introduced back in early 7.0 was to checkout these prefabs during merge... and in this case it is a recipe for disaster. Plastic tries to lock Car.prefab; it can't because it is already locked and... you can't merge! Blocked until Car.prefab is unlocked.
Now we fixed this, and the checkout is not needed if the file is not in conflict, and this scenario can proceed.
Why we didn't see this coming? Well, because Plastic is designed to work in branches, so we didn't foresee this. Working on single branch is not a problem either, but mixing people doing locking with people doing merge on the same branch wasn't something we expected.
I mean, normally developers would modify code in branches, so the scenario above wouldn't happen. But if you make it on main branch, it does.
Now the issue is solved, and that's good, and it is just a step to do simple things simpler; I mean, we are super good with branching and merging, and we'll be very good in single branch (which is simpler!!) too.
A word on game dev strategy and wrapping up
All these changes happened for a reason: we want to make Plastic SCM the best version control software for game development.
We are close, because we are the only distributed version control system that can do huge files and repos (like 8TB repos, no problem) natively, without hacks, and do native centralized too (checkin and forget, no need to push). You have Git doing part of this. You have P4 doing the other. But Plastic can do both which opens an incredibly good use case for teams in games.
As I said, we are committed to continuously evolving the product in this direction and deeply grateful to all the studios that share their knowledge with us and support us in the trip.
0 comentarios: