Perforce Public Knowledge Base - Changing the Default Integration Engine
Reset Search
 

 

Article

Changing the Default Integration Engine

« Go Back

Information

 
Problem
In the 2011.1 version of the Perforce Server, a new (generation 3) integration engine was introduced. In the 2013.2 version of the Perforce Server, the generation 3 integration engine became the default. Prior to the 2013.2 P4D release, the generation 2 engine was the default. 
 
This article describes how to identify which integration engine you are using, how it can be changed, and the consequences of changing the default integration engine.
 
 
Solution
For background on  the differences between the integration engines, please see the following KB articles:
To identify which integration engine you are using, run one of the following commands:
 
p4 configure show

or

p4 -ztag info

If neither of the above commands displays the dm.integ.engine variable in the output, then you are using the initial 2011.1 release where the generation 3 engine was set as the default.
 
To use the generation 2 integration algorithm with a 2011.1+ server, run:
 
p4 configure set dm.integ.engine=2

To use the generation 3 integration algorithm with a 2011.1+ server, run:

p4 configure set dm.integ.engine=3


Using dm.integ.engine=2

When using the generation 2 engine, the server integration engine functions as it has in 2010.2 and earlier versions of p4d (going back to 2004.2). When using dm.integ.engine=2, however, most features of the generation 3 engine are disabled. Those newer features are detailed below.

Using dm.integ.engine=3

In the generation 3 engine, the following functionality was introduced:
  • Resolving "move" actions
    Files that have previously been "moved" within the source and/or target branch will be paired up if there was common integration history prior to the move. When the range of source changes to be merged includes "move" actions, a special resolve will be scheduled to accept, ignore, or merge the move action.
     
  • Resolving file type and attribute changes
    When the range of source changes to be merged includes filetype or attribute changes, a special resolve will be scheduled to accept, ignore, or merge the change. (This eliminates the need to use the -t flag to ensure that filetype changes are propagated.)
     
  • Multiple resolves around previous integrations
    The new -Rs flag forces multiple resolves to be scheduled per source file when there is a non-contiguous set of unintegrated changes. This prevents previously "cherry-picked" changes from being re-integrated, at the cost of requiring additional merge steps during "p4 resolve".
     
  • Modified base selection
    The generation 3 integration engine examines the detailed integration history of the source and target files and picks a base with the greatest number of changes in common with the source and target files. The generation 3 integration engine picks a superior base in many complicated scenarios compared to the generation 2 engine. For the best integration performance it's a good idea to keep your server current with the latest release.
Reasons for Changing Integration Engines

Since the generation 2 algorithm has been in place since 2004, many sites have very tightly coupled their integration processes with the behavior of the generation 2 algorithm. If this is the case, or the results from the integration 3 engine are unexpected or problematic, the dm.integ.engine configurable can be set to 2, if it is not already in effect.

For complicated integration histories, users will enjoy the additional benefits of the generation 3 base selection algorithm, handling delete resolves, merging content across moved files, and resolving file type and attribute changes.

Note:  
The generation 3 engine is always in use for streams-enabled depots, even when the server is configured to use the generation 2 engine.

 
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255