Hacker News Reader

Comment by learc83 | Hacker News Reader

In addition to large binary asset files, in Unity you have tons of yaml files that you don’t edit by hand. If you make a small change to a scene with the editor, it can change dozens of lines in the corresponding yaml file.

Now imagine 2 people working on the same scene. When you attempt to merge, you have to read and understand an auto generated file that was never intended for human consumption.

To a lesser degree, it’s analogous to using line based source control on a jpeg to handle merging edits made in photoshop.

View on HN

PHP's Composer package manager has this same problem. Basic Drupal updates used to be a total pain in the ass - any attempt at a Git merge would most likely corrupt Composer state as the default merge drivers don't have a clue how to generate valid JSON.

There's a custom Git merge driver for composer.json and composer.lock files. It can't generically merge all JSON but it's good enough to make merging upstream updates on a composer-managed project at least sort of tenable.

This is entirely a tooling and time problem: it would be possible for Unity to ship with a Git merge plugin for their file formats, and add merge-conflict resolution to their editor, which would enable using Git with Unity. They're an ECS, which means all their objects and components of those objects should (and I stress, SHOULD) have unique identifiers that they can use for resolving merges. However, I imagine that isn't terribly easy to write and they probably have better uses of their time since everyone likes using Perforce anyway.

So.. how is source control done then? Centralized/lock-based (subversion)? Everyone works off the same shared NFS drive? Manually copy "changed" files from multiple people over top of each other and hope for the best?

Centralized/lock-optional, and very large repositories.

Merging Unity files is somewhat tractable. You can try to resolve merge conflicts by hand (it sometimes works!) and you can split things apart into prefabs.

Sounds like the yaml shouldn't be in source control. I've always followed the guideline: If it's generated by the computer from some other thing, then put the other thing in source control.

It's not generated from another thing. It's the editor's save format, so it's the direct output of human work. It's just not in a 'genuinely' mergeable format.

The fact is, that we take VCS for granted as programmers, but the vast majority of people don't have access to workflows that allow for true multi-user collaboration or branching/merging. Google Docs was a revolution because even though real-time joint editing is not that great and no substitute for the "work independent, review, merge" workflow developers use, it's still better than emailing Word docs to each other. Which is BTW still extremely common even in firms where they have Office 365 - most people never learned about the sharing and collab editing features.

On a game most people aren't devs. So VCS is less relevant to them, and git especially so, for the reasons someone else discusses below. Note the mention of Perforce in the article. Why are they using expensive proprietary VCS? Well, Perforce is better at handling fully centralised workflows with large binary assets.

Reply on news.ycombinator.com