Questions about setting up Perforce

Development Programming & Scripting C++
,
1

Happy Thursday, everyone! I hope you’re all doing well.

I have a few questions about setting up Perforce. I’m a small developer with a few people helping me out sporadically, and I’ve been wrestling with Perforce for a while. I think I’m close to getting it set up, but I’m running into a few issues that I haven’t been able to resolve online.

  1. Is it recommended to have a separate depot with a stream specifically for the engine, and then another depot for the project that sources the engine stream? Why would we do this instead of just having a single depot with a stream that includes both the engine and the project?
  2. I believe I’ve set up my Type Map and P4 Ignore correctly, but I keep getting errors about files with wildcards in their names. From what I understand, this should be fine—is that correct?
  3. I’m also getting errors for files ending in .rc. I can bypass this by setting the file type to “text,” but is this the right approach? Why isn’t this being handled by the Type Map?

Thanks for any insights you can provide!

here is an example of the RC error

 Translation of file content failed near line 1 file C:\QuantumWinter\UnrealEngine-release\Engine\Source\ThirdParty\nvTextureTools\nvTextureTools-2.0.6\src\project\vc8\nvzoom\nvzoom.rc

Here is my p4 ignore

Saved/

LocalBuilds/

*.csproj.*

*.vs/*

*.pdb

*.suo

*.opensdf

*.sdf

*.tmp

*.mdb

obj/

*.vcxproj

*.vsconfig

*.sln

*-Debug.*

*FileOpenOrder/

*.xcworkspace

*.xcodeproj

*./Makefile

*./CMakeLists.txt

.ue4dependencies

*Samples/*

*FeaturePacks/*

*Engine/Documentation/*



# Engine intermediates

*Engine/Intermediate/*

*Intermediate/



# Intermediate folders for programs should not be checked in

*Engine\Programs\*\Intermediate\*



# Intermediate folders created for various C# programs

*Engine\Source\Programs\*\obj\*



# Saved folders for programs should not be checked in

*Engine\Programs\*\Saved\*

*Engine\Programs\UnrealBuildTool\*



# Derived data cache should never be checked in

*Engine/DerivedDataCache/*



# Ignore any build receipts

*Engine/Build/Receipts/*



# Ignore personal workspace vars

*p4config.txt



# Ignore Unix backup files

*~



# Ignore Mac desktop services store files

*.DS_Store



# Ignore crash reports

*crashinfo--*



# Ignore linux project files

*.user

*.pro

*.pri

*.kdev4



# Obj-C/Swift specific

*.hmap

*.ipa

*.dSYM.zip

*.dSYM



# Ignore documentation generated for C# tools

*Engine/Binaries/DotNET/UnrealBuildTool.xml

*Engine/Binaries/DotNET/AutomationScripts/BuildGraph.Automation.xml



# Ignore version files in the Engine/Binaries directory created by UBT

*/Engine/Binaries/**/*.version



# Ignore exp files in the the Engine/Binaries directory as they aren't C/C++ source files

*/Engine/Binaries/**/*.exp



# Ignore Swarm local save files

*Engine/Binaries/DotNET/SwarmAgent.DeveloperOptions.xml

*Engine/Binaries/DotNET/SwarmAgent.Options.xml



# Intermediary Files

*.target.xml

*.exe.config

*.exe.manifest



# Ignore project-specific files

*/Build/Receipts/*

*/DerivedDataCache/*

*/Binaries/*

*/Binaries

*/Intermediate/*

*/Plugins/Developer*



# idea

# Default ignored files

*/shelf/*

*/workspace.xml

*/.idea/*

*.idea*



# vs code



*/.vs/

.vs/

.vs/*



*/.vscode/

.vscode/

.vscode/*



*/.name/*



*.swp



# no tmp directory

*tmp*



# User-specific folders

*Build/*

*Builds/*

*FileOpenOrder/*

here is my type map

# Perforce File Type Mapping Specifications.
#
#  TypeMap:	a list of filetype mappings; one per line.
#		Each line has two elements:
#
#  		Filetype: The filetype to use on 'p4 add'.
#
#  		Path:     File pattern which will use this filetype.
#
# See 'p4 help typemap' for more information.

TypeMap:
	binary+w //depot/....exe
	binary+w //depot/....dll
	binary+w //depot/....lib
	binary+w //depot/....app
	binary+w //depot/....dylib
	binary+w //depot/....stub
	binary+w //depot/....ipa
	binary //depot/....bmp
	text //depot/....ini
	text //depot/....config
	text //depot/....cpp
	text //depot/....h
	text //depot/....c
	text //depot/....cs
	text //depot/....m
	text //depot/....mm
	text //depot/....py
	text //depot/....rc
	binary+l //depot/....uasset
	binary+l //depot/....umap
	binary+l //depot/....upk
	binary+l //depot/....udk
	binary+l //depot/....ubulk
2

You don’t necessarily have to do a separate depot for the engine (I don’t at home but we do at work). It’s just another tool to organize your data.
But it is a good idea to give it a separate stream. First it keeps things separate and provides a way to manage permissions without having to mess with file paths (if you use import instead of import+ no one can accidentally make engine changes you don’t want). Second it makes it easier to share if you make separate depots for multiple projects. For hobby development it might not matter, but in a professional setting each project should have a separate copy of the engine so that you minimize the impact of updates needed by one project on others. Third it makes it easier to manage upgrades because you can keep a series of streams for the engine for propagating changes.

For example we have a stream for each minor-version release of the engine (5.1, 5.2, 5.3, etc). Then we have a stream that is the latest version of the engine (copied from the most recent version release stream). Then we have a stream were we’ve applied our studio engine modifications, which the latest version stream is merged into when it’s updated. Each project then has a staging stream of the engine where updates to the engine can be tested against the project. The studio engine and a project engine stream are both merged together and tested in that stream. Then once the project update is complete, it’s copied back to the project engine stream which is when it’s rolled out to the team at large.

That sounds like a lot. Like a lot, a lot. And it is, but it also makes it pretty easy to take updates and limits the ability for the upgrade process to mess up active project work. And it allows for each project to update when it make sense for them and not have to coordinate an update across and entire studio.

You can check out the recent video from Riot at Unreal Fest that goes over their (almost identical) setup (https://www.youtube.com/watch?v=9xxwQVdwcTQ). Though the talk is very light on perforce nity gritty.

Sorry that I can’t really help with the other two issues.

1 Like