Perforce: Code management setup

Hey there,

we started using Perforce for source control. Im pretty new to this stuff and thought it a bit easier at the beginning. Everything is setup and working. We until now we have been 2 guys, a programmer and a designer. This is out setup at the moment:

As we are working on multiple small projects and have some functions that are usefull for all projects, we made a project that consists of modules that can be implemented by other projects.

CLIENT1 is the programmer. He gets the code of the working project and adds modules from the MODULEPROJECT. Compiles the code and uploads the binaries. CLIENT2, the designer, gets the binaries and can continue working.
CLIENT1 can make changes to the module sources from every workspace.

Now we got a new programmer and fun starts to happen. Lets assume CLIENT2 to be the new programmer. CLIENT2 gets PROJECT1. The issue: He only got the sources of PROJECT1, not the sources for the modules that CLIENT1 uses. Thus CLIENT2 can’t compile, as the build target (…target.cs) assumes modules that CLIENT2 does not have in his workspace. CLIENT2 now needs to manually map the needed modules to his workspace in order to compile. CLIENT2 should get the module sources, as he should be able to make changes to them as well. CLIENT2 now adds another module to the project. Now CLIENT1 misses the module and needs to manually add it to his workspace (Map it to the workspace). This is a realy tedous process and explodes to unuseable as more programmers join in.

What we need would be something like this:

The module sources reside in the MODULEPROJECT where they belong to and ONLY reside there. PROJECTX references the modules from the MODULEPROJECT. Someone gets the PROJECT1 and automatically gets the needed modules. Every programmer is able to make changes to the module files and submit them, what updates the files in the MODULEPROJECT.

Unfortunately I can’t find a way to set this up. I’m up for a better structure as well if you got one to share.


The answer is to simply put the module in each project and just routinely integrate from the main module branch to all projects. This keeps all the projects up to date with the latest module code, and allows each module to be independent and compile properly.

So, for example, with Able, I have to test it in multiple engine versions so my perforce depot looks something like this:

  • Able Main - contains the latest Able code.
  • UE
    • 4.14.3 - Engine Source (Contains a copy of Able that was branched from the mainline after the initial depot submit).
    • 4.15.2 - Engine Source (Contains a copy of Able that was branched from the mainline after the initial depot submit).
    • 4.16.2 - Engine Source (Contains a copy of Able that was branched from the mainline after the initial depot submit).

So, I’ll make a bug fix in one of those branches, integrate it back into Able Main, and then integrate that out to the other branches. So all branches are kept in sync, all work independently, and everyone is happy.

Talking about Perforce, I would probably to recommend to use Perforce Streams. Then you can setup rules per each stream, witch can share, import etc folders from depot. So, you can combine workspace from different blocks.

I actually loathe streams. Not being able to customize the client spec (you have to create a new stream…) drives me insane. Same with integrations using streams.

Thanks for your replays.

Just trying this. Creating the branch seems pretty easy, just define the target folder to be within the TargetProject. Now updating the workspace for the TargetProject, sucks in the file from the module branch without creating any mappings for the workspace. Seems to be exactly what we need and usable for bigger teams, as everyone gets the files he needs.
Unfortunately, from the perspective of someone else, this module branch is just a module within the unreal project. How to know it comes from somewhere else? And making changes to the module branch (just a module from the perspective of someone else), how do they know that they should integrate it back into main? Keep in mind that there could be other project related modules as well, thus it can get quite messy (Maybe name the module like: UE4Module_MODULENAME to seperate those?).

Had a look into streams as well. They seem to be more of what we need, but with other issues.
I created a new depot and defined it as stream. Within this StreamDepot I made a new stream Main. Within the ‘Path’ field I define mappings that suck in the project files and modules with ‘import MAPPING’. Creating a workspace on stream Main, looks dam good, everything we need is there. Now the issue: I cannot edit the files as they have been imported …

Creating a Stream that is the UnrealProject itself and importing just the Modules, allows me to edit the project files but not the module files. Am I missing something?

Usually I am using “import” for modules witch I am not changing but. For example, Plugins, fbx sdk etc.

If I need to make changes, then I am using normal “share…” in “Paths” and changing local path in “Remapped” of my Stream properties.

‘share …’ is only possible to stuff that exists in the parent stream. I got my modules files seperate from the main stream and could not use ‘share …’ for those.

My solution for now: I placed all projects within a single mainline stream, including the module project. From there I can create substreams that consist (‘share …’) only what is needed for that project. Then I use the 'Remap" part to move the shared modules to the correct location within the sources.

After I was done doing so, I noticed there is ‘import+ …’ that is missing from the docs, came about it in a blog post. It is the same as ‘import …’ but allows writing to the file.