Hi,
We’re evaluating whether to consolidate our Perforce setup or keep it split across multiple commit servers, and we’d appreciate Epic’s perspective on one specific question from our internal review.
Background
We run several separate Perforce commit servers, one per project, each with its own edge servers. Two of those project servers were split off our main cluster some years ago as a temporary workaround while the main server was slow; that constraint no longer applies, but the split has persisted.
Cross-server sharing today works only via one-way DVCS fetch into mirror depots, followed by a local p4 integrate from the mirror. Native p4 integrate, virtual-stream import, and RoboMerge cannot operate across commit servers at all - this is the main source of friction we’re hitting (shared tooling, deploy patterns, agent/config sharing, merge workflows).
The storage cost of that split is significant:
- Project server 1: mirror content ~6.5 TB (three separate mirrors: 4.9 TB / 1.1 TB / 0.55 TB) vs native project content of 622 GB - mirrors are about 91% of everything stored on that server.
- Project server 2: mirror content ~2.6 TB (two mirrors: 2.4 TB / 166 GB) vs native project content of 109 GB - mirrors are about 96% of everything stored on that server.
Combined, roughly 9 TB exists purely because these projects sit on separate servers rather than one. A mirror also loses the lazy-copy benefit the source enjoys within its own server: the same subtree costs 48 KB physically as an in-server branch (31.7 GB logical) versus 66 GB physically as a cross-server copy (73.1 GB logical). Separately, our main/flagship server’s checkpoint currently runs 6+ hours, versus well under an hour on each of the smaller split-off servers.
From our licensee Perforce access, Epic’s own upstream server appears to hold multiple engine generations and at least one shipped title together, separated by streams rather than by server (Replica of: <single upstream>, with distinct stream trees for each engine major version plus a shipped-title depot). We understand this is a filtered licensee replica, not Epic’s full internal infrastructure, so it may not represent every internal Epic project.
Questions
1. Blast radius: On Epic’s model, how do you contain the impact of an outage, corruption, a runaway process, or a long checkpoint/restore, when multiple products/engine generations share one server? Is isolation handled mainly via streams and protections, edge/standby topology, operational process, or something else?
2. Advice for a studio already split: Given a studio that has already moved some projects onto separate commit servers, what would Epic advise? Stay split and absorb the cross-server integration cost, plan a consolidation back onto one cluster, or a hybrid (e.g. shared/tooling depots on one server, game projects on their own)?
3. Horde / UGS / RoboMerge alignment: These tools appear designed around a single-cluster model (RoboMerge specifically relies on p4 integrate -S, which cannot cross servers). For studios running multiple clusters, is there a recommended pattern beyond DVCS mirrors, or does Epic expect licensees to consolidate?
4. Epic’s own tooling direction: Is “one server, separated by streams” still the model Epic would recommend to a licensee today? (Lore looks promising but isn’t ready for our production workflows today)
Why we’re asking
Our own rationale for the split was operational isolation (faster checkpoints, independent maintenance windows, smaller shared failure domain). Our engineering teams are hitting real limits from it (shared tooling can’t reach every project, stream imports fail across servers, merge workflows need manual workarounds). We want to understand how Epic manages blast radius at scale, and what you’d advise a studio in our position.
Thanks.
[Attachment Removed]