Perforce controls what syncs. Occlude controls what runs.

29 October 2026 · By the founder

"Perforce has done this for thirty years" is the objection we hear most from teams with Perforce in the building. It is fair. A Perforce protections table can give a contractor a depot where some files simply are not there. Here is what Perforce's manual says happens next, and why Occlude starts somewhere else.

What the manual says

Perforce grants rights per path in its protections table, p4 protect. To keep a contractor out of a file, you deny them the read right on it. The command reference is precise about the effect:

"If this right is denied, users cannot use p4 print, p4 diff, or p4 sync on files."

That is the point: the file does not sync, so it is not on the contractor's disk. It is also the problem. If the contractor's code imports that file, their build now fails, because the compiler on their machine cannot read what is not there.

The other choice is to deny less. Denying the open right stops them changing the file:

"If this right is denied, users cannot open files with p4 add, p4 edit, p4 delete, or p4 integrate."

Now the file syncs, the build passes, and the source sits on their laptop, readable. A Perforce administrator chooses between a broken build and a visible file.

Why version control cannot do both

That is not a flaw in Perforce. It follows from where version control sits. A version-control server decides what lands on a disk. Once a file is on the disk, anything that can read the disk can read it, and on a contractor's laptop the compiler and the contractor are the same user on the same machine. Hide the file from one and you hide it from both.

To keep a file from a person while the compiler still reads it, you need two readers the system can tell apart, and a runtime the person does not control. Version control ships neither.

What Occlude does instead

Occlude does not decide what syncs. It holds the full clone in a workspace in your cloud and decides what each side of that workspace can see.

• The person's side (shell, editor, language server) sees the task's files. An Occluded file is not there: cat answers No such file or directory, exactly as it would for a file that never existed. Where their code imports it, a declaration stub stands in, so autocomplete and go-to-definition still work.
• The build's side (compiler, tests, dev server) sees the whole repository and runs as a different user. npm run build reads the real file, so the build is the one you ship.

The contractor gets a working build without the file. The Perforce administrator never had that option.

Where Perforce still wins

If the protected code is a stable library behind a fixed interface, and contractors can live with linking a compiled binary, Perforce plus a shipped binary works and costs you nothing new. If the code changes every week, or the contractor edits next to it every day, the binary goes stale and the sync-time choice comes back. That is the case Occlude is for.

Sources

• p4 protect, the Helix Core command reference, for both quotes.
• Our docs: The four states and Stubs.

All posts