Perforce (and other version control) best practices

[Neverender]

I've decided to set up my own Perforce server and am trying to figure out the best way to organize and manage UE4 projects. I'm hoping to get the official word on some of this stuff! I considered putting this on AnswerHub instead, but it's a very broad topic.

I briefly looked into using Perforce Git Fusion, but if you don't start with their virtual machine appliance, the configuration looks somewhat painful - it also chews through 4 of your 20 free users for automation tasks. I know Epic uses Perforce internally and has mentioned looking into more directly mirroring the internal Perforce changelists to the public-facing GitHub project. However, I don't get the impression the GitHub repository is ever intended to be canonical, as opposed to a replica of (a subset of) their internal Perforce depot. Does Epic use make use of git internally, via Git Fusion or otherwise?

I'm not yet using a customized build of the engine, but I expect to eventually. Is there a recommended organization for the engine alongside dependent projects? Do you use separate depots?

I assume that the third-party dependencies live in the Epic Perforce depot, as opposed to the GitHub repository where they are excluded. Are these dependencies expected to change frequently with updated engine builds? Can we rely on this to be mentioned in the release notes, or should we always assume they've changed and redownload both monolithic zip files?

I found this entry on AnswerHub where someone from Epic recommends against committing the solution or project files to version control. Does that mean every developer individually re-binds to source control in Visual Studio each time those files are regenerated? Also, although it's not mentioned, I assume it's best to exclude the DerivedDataCache directory.

-----
EDIT #1:

Binaries are checked in with +w on the file type so those who build the project do not run into "File is read-only" errors."

Does this mean all the EXE and DLL files in Engine/Binaries/Win64? If so, should the corresponding PDB files also be checked in? Are they used for crash reporting or anything like that? Also, it seems like using the <binary+Sw> filetype would make sense here (only store the most recent revision), since you should probably never need to be able to sync an older compiled revision of the engine.
-----

I'm sure I'll think of more questions later, and depending on the responses I get, I might try to put together a wiki article about this.

Thanks in advance for any replies!

[mikepurvis]

This is something I'm interested in. I am using a Perforce repo as well. My team is 2 people though so, I kept it simple, just checked in everything except the Intermediate folder.

It probably depends on the team. Artists may want to be working from an installed or built version and not have anything to do with the code repo, that way programmers can break the build for each other and deal with it without effecting the Artist's workflow who are only working off "stable" builds.

On my last project, it was UE3. I pulled the UE3 engine code down from Epic, then had a separate Perforce repo for the game. It was very difficult to merge changes in UE3 into the project with that setup. I believe the best way is to have 3 repo's in Perforce. The Engine, Merge, and Development. It seems labor intensive. Git may handle it better, I'm not sure.

[InfectedFPS]

I found this entry on AnswerHub where someone from Epic recommends against committing the solution or project files to version control. Does that mean every developer individually re-binds to source control in Visual Studio each time those files are regenerated? Also, although it's not mentioned, I assume it's best to exclude the DerivedDataCache directory.

I ran into this issue when originally setting up my project for source control. After talking with Michael Noland and some browsing on the AnswerHub I found why they recommend this.

Here's all I store in my repository for a UE4 project.



So when we pull the proejct we go to the folder where it's stored locally, right click on the .uproject, and click "Generate Visual Studio Files"



.gitignore

Binaries/
DerivedDataCache/
Intermediate/
Saved/

*.filters
*.opensdf
*.sdf
*.sln
*.suo
*.user
*.vcxproj

[Neverender]

Artists may want to be working from an installed or built version and not have anything to do with the code repo, that way programmers can break the build for each other and deal with it without effecting the Artist's workflow who are only working off "stable" builds.

Yeah, the need for content creators to have a reliable build is important. I edited my original post to add some questions related to that. But at the point that you've customized the engine for your project, using the "installed" version (in the sense of an official Epic build downloaded from the launcher, which is what I assume you meant) becomes a non-starter. Worrying about this may be putting the cart before the horse somewhat, but it seems worth spending some time considering.

If you don't have automated builds like Epic does, the best balance I can think of is to have programmers manually commit freshly built binaries when they're reasonably confident things aren't broken. Either way, to some extent, artists sync at their own peril.

On my last project, it was UE3. I pulled the UE3 engine code down from Epic, then had a separate Perforce repo for the game. It was very difficult to merge changes in UE3 into the project with that setup. I believe the best way is to have 3 repo's in Perforce. The Engine, Merge, and Development. It seems labor intensive. Git may handle it better, I'm not sure.

Yeah, I think doing all the engine work inside a GitHub fork and then occasionally mirroring a snapshot over to Perforce may actually be the best option. It's possible Perforce Git Fusion has something to offer here, but frankly I can't tell because their documentation and even marketing materials are impenetrable.

[dzeligman]

I'm also curious about the standards for version control and setting up UE4 builds. I havent had any issues getting code from fellow programmers and regenerating the new VS projects, however, I don't want my artists or designers to have to do that whenever we add new code. Thus I'm unsure of what dlls or binaries are acceptable/needed for them to have their own set editor build.

[Neverender]

Just a quick bump to mention that attempting to package a project from the editor will cause errors unless the following files are marked as writable in Perforce:

Engine/Binaries/DotNET/AutomationTool.exe
Engine/Binaries/DotNET/AutomationTool.exe.config
Engine/Binaries/DotNET/DotNETUtilities.dll
Engine/Binaries/DotNET/DotNETUtilities.XML