常见合并问题

合并引擎的新构建版本时经常会碰到的多个问题的说明。

Windows
MacOS
Linux

工具

以下是建议用于合并和集成虚幻引擎4经QA审核的构建版本的工具:

  • Araxis Merge:http://www.araxis.com/merge/

  • Perforce:http://www.perforce.com/

合并

Araxis Merge等工具对于处理合并非常有用。可将它集成到Perforce等版本控制系统中,这样,你就可以使用Araxis处理对比/合并,而非使用内置的工具。

合并已完成的构建版本时,Araxis Merge中的文件夹对比(双向和三向)功能可帮助将当前项目与最近的经QA审核的构建版本和与之前的经QA审核的构建版本(在某些情况下)进行对比。此策略使你可以了解在经QA审核的构建版本中以及当前项目中,哪些部分已改进。

在合并时在Perforce等版本控制系统中创建分支也非常有用。在不同分支中处理所有与合并相关的变更可使基分支保持简洁,直至你准备好将完全合并后的变更集成过来——这通常在运行一些回归测试并且所有问题都解决之后进行。

当然,最佳实践始终是采用一种适用于引擎的模块化方法并严格执行,而不是将全部内容都放在基线中。使基线尽量保持简洁可减少很多与合并相关的错误。

另一个适用于管理合并代码的策略是,确保你在基础构建版本代码中添加易于理解的注释,这样做可便于辨识进行过变更的片段。

//myproject - 修改基础代码...

为项目添加#define也非常有用:

#define YOURGAME 1

然后,你就可以在基础引擎代码中的自定义代码部分使用它进行区分:

#ifdef YOURGAME
   //myproject - 在此处编写了自定义代码...
#endif // YOURGAME

理想情况下,你需要能够取消定义一切,以便拥有通用构建版本,但是这种做法并非始终可行。

无论如何,这些技巧都能够使合并变得更加稳定。

集成

每个QA构建版本都经过大量重大变更。某些变更涉及大量文件,这大大增加了合并难度。

处理这些问题的一个好方法是使用Perforce中的集成功能。

  1. 准备一个公用文件信息库(Depot)区域,用于QA内部版本。(例如, //depot/UE4Builds/...)

  2. 在新QA内部版本完成时,下载它,然后提交到公用文件信息库(Depot)。

    提交所有文件添加/删除/编辑处理的一个好方法是使用下列命令:

    REM PURPOSE:  make certain the default changelist in your default clientspec is empty
    
    REM takes 2 variables
    REM %1 == the hard drive PATH (under the depot root) to the dir with the new version (e.g. c:/foo/bar/baz)
    REM %2 == the depot path to the build (e.g. //depot_foo/bar/baz/...
    
    REM USAGE:  p4ModifiedFiles.bat c:/foo/bar/baz //depot_foo/bar/baz/...
    
    REM save state
    set MODFILES_FIND_ORIG=%MODFILES_FIND%
    set MODFILES_FIND=C:\bin\cygwin\bin\find.exe
    
    REM find all of the new files and add them
    %MODFILES_FIND% %1 -type f | p4 -x - add
    
    REM open all changed files for edit
    p4 diff -se %2 | p4 -x - edit
    
    REM open all removed files for delete
    p4 diff -sd %2 | p4 -x - delete
    
    REM restore state
    set MODFILES_FIND=%MODFILES_FIND_ORIG%
  3. 使用Perforce的集成(p4 integ)从//depot/UE4Builds/...集成到Perforce中的引擎(例如,//depot/MyEngine/...)。

  4. 使用Perforce的"安全自动解决冲突(Safe Automatic Resolve)"自动解决未在本地更改的文件存在的冲突。(例如,版权更新基本上会影响所有文件。而很多文件都未在本地更改。)

请参阅:http://www.perforce.com/perforce/doc.062/manuals/p4wsad/topics/resolving.html

安全自动解决冲突(Safe Automatic Resolve):如果你的文件或他们的文件(但不能两个文件同时)与基本文件存在差异,接受该文件的存在差别的版本作为最新版本。如果两个文件都与基本文件存在差异,则不对此文件执行冲突解决。

创建分支

"创建分支的时间要尽可能晚"是一个典型的分支策略,目的是尽可能减少代码侧和内容侧分支中的更改。

创建分支后,该策略有助于与分支中发生的变更保持一致(通常要求负责特定分支中发生的变更的人员在适当时集成和合并相关变更)。

错误和故障排除

"非类或命名空间名称(Not a class or namespace name)"错误

症状: FooClass.h文件的DECLARE_NATIVE_TYPE()宏的某个类出现"非类或命名空间名称(Not a class or namespace name)"错误。该类已在FooClasses.h文件中该宏的上面声明,但是可能由于一些#define在包含该文件时处于有效状态,该宏无法理解该声明。

原因: 包含在LaunchEngineLoop.cpp(定义为NAMES_ONLY)中的某个自动生成的头未包含在预编译的头(没有定义为NAMES_ONLY)中,造成编译错误。

解决方法: 在预编译的头中包含自动生成的头,并且将该预编译的头定义为NAMES_ONLY。

请参阅:https://udn.epicgames.com/lists/showpost.php?list=unprog3&id=10516

枚举冲突

症状: 授权用户和Epic添加了具有相同值的枚举。

原因: 枚举按值序列化,而非按名称。

解决方法: 一个解决方法是创建修补内容的commandlet,但执行该任务时易于发生错误而且该任务比较耗时。对于授权用户,一个更优的短期解决方法是填充枚举。在C++中,这非常容易实现,只需在枚举中指定偏移即可,但是在蓝图中,必须手动添加填充条目。

针对此问题的解决方案涉及引擎级别的变更,该变更会将所有枚举作为FNames序列化,而非按值。这是一个尚未完成的任务:41337。这一变更会增加重命名枚举的难度,但基本上不太会需要重命名枚举。

请参阅:https://udn.epicgames.com/lists/showpost.php?list=unprog3&id=21598

Select Skin
Light
Dark

Welcome to the new Unreal Engine 4 Documentation site!

We're working on lots of new features including a feedback system so you can tell us how we are doing. It's not quite ready for use in the wild yet, so head over to the Documentation Feedback forum to tell us about this page or call out any issues you are encountering in the meantime.

We'll be sure to let you know when the new system is up and running.

Post Feedback