It's highly recommended to read this guide before setting up production depots and users. There are few critical details of repository configuration you should be aware before even putting project on the Perforce server.
Both Epic's live streams present setting up and using Perforce.
It's highly recommended to create your depots on Perforce as "stream depots" which are very useful, but it's not possible to convert the "default" depot to the "stream" one.
The official Streams Overview.
Stream depots allow for much easier managing of the depot. For instance, you can have "Coders" stream configured in such a way that any binaries compiled by programmers are ignored by Perforce. A standard practice with Unreal Engine is to have a "build system" compiling binaries (after every change in source code submitted) and publish it to the team.
Without stream depot, you would have to configure the same things manually for every single workspace.
- Using Perforce as Source Control - a page from the official docs explaining with example typemap
And here's go the typemap we should cover all common filetypes, including types used while pushing the engine source to the repository. Also if using Perforce to store asset sources created by artists.
binary+l //....uasset binary+l //....umap binary+w //....3ds binary+w //....abc binary+w //....ai binary+w //....aiff binary+w //....blend binary+w //....bgeo binary+w //....bmp binary+w //....dae binary+w //....dds binary+w //....dxf binary+w //....exr binary+w //....fbx binary+w //....flac binary+w //....geo binary+w //....gif binary+w //....glb binary+w //....gltf binary+w //....hip binary+w //....hipnc binary+w //....hmv binary+w //....jpg binary+w //....jpeg binary+w //....ma binary+w //....mb binary+w //....mp3 binary+w //....mp4 binary+w //....obj binary+w //....ogg binary+w //....pic binary+w //....picnc binary+w //....png binary+w //....psb binary+w //....psd binary+w //....sbsar binary+w //....skp binary+w //....spp binary+w //....tga binary+w //....tif binary+w //....tiff binary+w //....usd binary+w //....wav binary+w //....wmv binary+w //....vfl binary+w //....zpr binary+w //....ztl binary+w //....exe binary+w //....dll binary+w //....lib binary+w //....app binary+w //....dylib binary+w //....stub binary+w //....ipa binary+Sw //....pdb text //....c text //....config text //....cpp text //....cs text //....h text //....ini text //....m text //....mm text //....py text //....txt text+w //....DotSettings text+w //....modules text+w //....target text+w //....version
File locking is a standard feature of Perforce. Basically, all binary file types submitted to the repository should have such entry in the typemap.
Every file submitted to the Perforce repository is set to read-only. It's crucial when working with binary assets, the user has to either:
Check out the file before editing. If the filetype is "lockable", checkout it exclusive. That means that no one else is allowed to check out this asset. Now you and only you are allowed to submit the asset. Some teams prefer to set .uassset to
binary+w, this prevent situation when someone would lock the asset for everyone for a longer period of time.
Make it writable. It allows saving assets on your drive while someone else locked it. This allows you to temporarily change assets and continue your work. You won't be able to submit changes until the asset is locked by another person. And it this other person would submit a changed file, you need to discard your changes and download the latest version of the asset.
If that's important, you can that other person to Revert the file (discard changes and unlock the file) or simply Unlock the file via Perforce client.
This action should be avoided, if not really needed. You might forget that you modified this asset and could take a while to debug "why my game works differently for me than all teammates".
Binary, but temporary files
You can tell Perforce to store only the last version of the file, by filetype. This is useful for debugging symbols (.pdb) - a single version of symbols for the compiled engine is about 20 GB. Although you don't need to version it, it's just useful to provide debugging symbols to non-programmer people - so they could get a descriptive callstack in case of a crash.
Text-based files don't need exclusive checkout. If two programmers would submit conflicting versions of the file, it can be easily merged.
Make sure that programmers in a team use Perforce integration in their IDE. Without it they would have manually check out every single file they're about to edit. It's totally redundant and annoying. Every programmer would hate Perforce for that.
With Perforce integration configured (IDE connected to your Perforce server like the UE editor), every time programmer starts to edit a text file (.h, .cpp, .cs and so on), IDE will automatically check out the file. It should be an invisible action to the programmer, like with Git.
Visual Studio doesn't provide Perforce integration out of the box. Programmers need to install a free official plug-in called P4VS.
There's also a plug-in for VS Code.
Rider comes with Perforce integration built-in :)
Writeable text files
Some types of text files are modified during C++ compilation. These filetypes should be always writeable locally. Otherwise, compilation would fail.
Perforce system has "users" and "workspaces" which can be confusing before you start using it, especially when looking at licensing terms. Albeit it's very simple. Generally, Perforce is very easy to use for non-tech savvy people.
Access levels are set per user.
There's a special Admin user, usually the first user auto-created while opening P4Admin for the first time. It has all privileges, configuring other users, groups, depots, access restrictions. All the power.
Regular users can have different access to data on the server. For instance, Design users read/download the entire project, but modifying anything in the engine folder is blocked. This prevents accidental changing some engine's content. Also, regular users never download folders with the source code (it's approx. 100K files in the engine's Source folder).
Now Code users are allowed to change anything in the engine folders and see all the code, but asset sources are hidden from their view (if such sources are stored in the repository). This way programmers simply never download files used by Digital Content Creation tools, like Maya or FMOD.
FMOD project and sound sources would be visible only to Audio users.
Also, every user can have a different password. Although many studios set the same password for every developer. Simply, nobody needs privacy on a team-shared repository. And this makes things easier if a given person goes for a long vacation, but someone else needs to access files locked by this person.
All the operations on files, commits and changelists are bound to the workspace, not the user. This way every user could use multiple workspaces.
One workspace used in the office, another one while working remotely.
Or your default workspace belongs to Code user, so you can download and compile the code. But sometimes you want to access the FMOD project to test a game feature related to FMOD. You can simply a new workspace under Audio user just for this purpose.
Your personal preferences are saved to the workspace.
You can change folder mappings, i.e. Unreal project could be synced to "C:\MyProject" folder, but a folder with the custom engine could be downloaded elsewhere, i.e. "D:\Engine".
You can also exclude specific folders or files from being ever synced.
The Advanced tab in the workspace settings window hides many useful things.
Talks for advanced users, presenting Epic's take on branching. Also showcasing Unreal Game Sync - which is a tool based on the Perforce.