cloudparts

Perforce P4Renamed

A centralized version control server built for huge repositories and big binary files, long the standard in game studios: the server knows who has every file open, can lock files exclusively, and structures branches as streams.

What it is
Version control
Type
Commercial product
Made by
Perforce Software
License
Proprietary (free for up to 5 users and 20 workspaces)
Status
Renamed. Called Helix Core until March 2025, and Perforce, or P4 for short, before that.
Facts checked
20 October 2026
Website

What it is

One P4 Server (p4d) holds everything. Metadata, such as changelists, users, permissions and which files each person has open, lives in its database (db.* files), backed up by checkpoints and a journal; the file revisions themselves live separately in depots on disk. Each user defines a workspace, a view that maps depot paths such as //depot/game/main/... to a local folder, and p4 sync fetches only the files in that view. Files arrive read-only. p4 edit opens a file for editing, makes it writable and records it on the server, so anyone can see who has it open with p4 opened -a. p4 submit sends a numbered changelist atomically: every file in it is saved, or none is.

What sets it apart is handling files that can’t be merged. Marking a file type with the +l modifier, for one file or for every .psd through the server’s typemap, makes it exclusive-open: only one person can have it checked out at a time, which avoids two artists editing the same texture. Modifiers like +S10 keep only the last ten revisions of bulky generated files. Branching is organized as streams: each stream records its parent and type (mainline, development, release, virtual, sparse), the server generates workspace views from it, and flow rules follow the principle “merge down, copy up”: a development stream merges in its parent’s changes first, then copies its finished work up. Git Connector, a separate service, stores Git repositories in the server and can mirror repositories from GitHub or GitLab.

Christopher Seiwald started writing Perforce in 1995; the product was known as Perforce, or P4 after its command-line tool, then as Helix Core, and since March 2025 as Perforce P4. Perforce says it is used by 19 of the top 20 AAA game studios and 9 of the top 10 semiconductor companies. It is free for up to 5 users and 20 workspaces, and paid beyond that. The latest server release is 2026.1 Patch 3 (October 7, 2026).

Why teams pick it

  • Built for size: Google ran its monolithic repository on one primary Perforce instance on a single machine, with custom caching, for more than ten years
  • Exclusive locks per file type, and a server that always knows who has which file open, suit binary art and design assets
  • Workspace views and sparse streams fetch only the paths you need instead of cloning everything
  • Streams turn a branching strategy into server-enforced structure: parents, stability levels and the direction changes should flow

Watch out for

  • Proprietary and paid beyond 5 users and 20 workspaces
  • Centralized: submitting and browsing history need the server, and edits made offline or without p4 edit must be found with p4 reconcile
  • Its own vocabulary (depots, workspaces, changelists, integrate, streams) and tools; Git users need Git Connector to keep using Git
  • Running it is real operations work: checkpoints back up only metadata, so the versioned files need a separate backup

Alternatives

What all version control have in common →Compare side by side →
Apache SubversionOpen sourceThe centralized version control system that replaced CVS: one server holds the history as a single numbered sequence of atomic commits, and clients check out any directory of it.Unity Version ControlRenamedCommercialUnity’s version control system, formerly Plastic SCM: one repository that programmers can use distributed, with branches and push and pull, while artists check files in straight to the server and lock what they can’t merge.

How it fits with other technologies

Sync a workspace, check out a locked binary, submit · bash

p4 set P4PORT=ssl:p4.example.com:1666
p4 login
p4 client                                # edit this workspace’s view of the depot
p4 sync //depot/game/main/...            # fetch the files in the view

p4 edit Content/Hero.uasset              # check out: writable, and locked if its type has +l
p4 opened -a Content/Hero.uasset         # who has it open, in any workspace
p4 submit -d "New hero mesh"             # one atomic, numbered changelist

p4 reconcile                             # after editing without p4 edit, e.g. offline

See it in a real stack

No architecture uses Perforce P4 yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1995–2026

Christopher Seiwald had worked at Ingres on porting, networking and databases, and thought he could build a better software configuration management tool. He started coding in 1995 from Alameda, California, and incorporated Perforce Software in August 1996. The product was called Perforce, and often P4 after the p4 command. Its Inter-File Branching let any set of files be copied within the depot as a codeline, with Perforce tracking the copies and propagating later changes between them (p4 integrate).

A central server that could take very large codebases became its niche. Google relied on one primary Perforce instance, hosted on a single machine with custom caching, for more than ten years before it built its own system, Piper. In 2011 Perforce added streams, which turned common branching patterns into built-in workflow. In March 2015 the company launched Helix, a platform aimed at large teams of artists, programmers and designers, and in February 2016 the private equity firm Summit Partners bought the company. Seiwald handed over as CEO, and after the ownership change and the purchase of Seapine Software the server was renamed Helix Core.

In March 2025 Perforce went back to the old name. Helix Core became Perforce P4, and related products followed: Helix Swarm became P4 Code Review, Helix DAM became P4 DAM, and the Snowtrack client Perforce had bought became P4 One. Releases continue twice a year: 2025.2 added a tech preview of a REST API, and 2026.1 changed how sparse streams branch files, only when a change is submitted.

Why it’s built this way

A server that tracks every open file
Because p4 edit registers each file on the server before it changes, the server can show who is working on what, enforce exclusive locks, and make each submit atomic. The cost is that everyday work depends on reaching the server.
Branches as copies of file sets, linked by integration
Perforce’s Inter-File Branching mimicked how people branched by hand, by copying files, but let the server record the copy and carry later edits from one codeline to the other, so any set of files could be branched.
Exclusive locking as a file-type setting
Merging and resolving aren’t meaningful for binary files, so the only safe way to avoid conflicts is to let one person edit at a time. Making +l part of the file type, set once in a typemap, applies it to every matching file automatically.
Streams: put the branching strategy in the server
Ordinary branches carry no rules about how changes should move. Streams record each branch’s parent and stability, generate workspace views, and steer merges down and copies up, so teams follow the mainline model without hand-maintained branch specs.

Timeline

  1. 1995

    Christopher Seiwald starts writing Perforce in Alameda, California

  2. 1996

    Perforce Software incorporated (August)

  3. 2011

    Streams arrive in the 2011.1 server

  4. 2015

    Helix platform launched (March)

  5. 2016

    Summit Partners acquires Perforce (February); the server becomes Helix Core

  6. 2025

    Helix Core renamed Perforce P4 (March 13)

  7. 2026

    P4 Server 2026.1 (May 19); Patch 3 on October 7

Sources19 · facts checked 20 October 2026

Improve this page on GitHub