Why game studios still use SVN in 2026

If you tell most developers in 2026 that you host your game on Subversion, you'll get a raised eyebrow. SVN is supposed to be the thing we all migrated away from a decade ago. But walk into a game studio — indie or AAA — and you'll find centralised version control everywhere. That isn't inertia. It's a fit.

Git won — and it deserved to

Let's be clear up front: this isn't a "SVN beats Git" argument. For distributed teams working on code — branching constantly, merging text, reviewing pull requests, working offline — Git is the right tool, and it earned its place. Nothing here is trying to take that away.

Games are a different kind of project

A game repository isn't mostly code. It's textures, meshes, audio, animation, level data, and built assets — large binary files that can't be merged line-by-line the way source can. And the team isn't all engineers: artists and designers commit alongside programmers, often outnumbering them. The tooling has to fit those people and those files, not just the engineers and the code.

That's why games never fully moved to Git, and why Perforce is still the standard at the top end. The centralised, lock-friendly model isn't a relic — it's a match for how games are actually built.

Three things the centralised model gets right for games

Per-directory access

Artists get /Art, engineers get /Source, and it's all one repository. Permissions live at the folder level, so you grant exactly what each person needs without splitting the project apart. With Git you'd be reaching for separate repos or submodules to do the same thing — added structure that artists shouldn't have to think about.

Large files, first-class

Commit the 2 GB .uasset directly. No LFS to configure, no pointer files, no separate store to keep in sync. Big binaries are just files in the repo, handled the way you'd expect.

Partial checkout

Pull only the folder you need. An artist working on world 3 doesn't have to drag the entire project — and its full history — onto their machine. You check out the slice you're working on and leave the rest on the server.

The quieter advantages

A few things that don't lead the pitch but matter every day: file locking, so two people can't silently clobber the same binary; compatibility with any SVN client, including TortoiseSVN, the command line, and Unity's built-in integration; and the fact that the SVN repository stays the source of truth — import and export are plain SVN, so there's no lock-in. You can leave whenever you want; the point is that you won't need to.

Where subforge comes in

subforge takes that centralised, binary-friendly model and makes it hosted and modern: a web UI for browsing files, history, and diffs, asset previews for images, audio, and 3D, per-path access control, one-click import, and backups — without a server to babysit. It's the workflow AAA pays Perforce for, sized and priced for indie teams. It's in beta and free while we build it out.