integrate -- schedule integrations from one file to another
p4 integrate [ options ] fromFile[revRange] toFile
p4 integrate [ options ] -b branch [ toFile[revRange] ... ]
p4 integrate [ options ] -b branch -s fromFile[revRange] [ toFile ... ]
options: -c changelist# -d -f -i -n -r -t -v
Integrate attempts to propagate changes between two sets of files:
from the source files of the branch view to the target files of the
branch view. The result is target files that are opened for the
action reflecting changes made in the corresponding source files.
The actions are either 'branch' (for new files), 'delete' (when the
source file was deleted), or 'integrate' (when the source file was
changed). In all cases, the opened files must be submitted with
p4 submit before the integration is reflected in the depot.
Files opened for 'branch' or 'integrate' are left read-only on the
client. For 'integrate', a subsequent p4 resolve command handles
the actual merging. If merging takes more than one editing session,
p4 resolve -f can be used to revisit a merge. In this normal case
a later 'p4 integrate -r' knows that the results of the merge don't
need to be merged back.
You can downgrade a file opened for 'integrate' or 'branch' to
'edit' or 'add' and gain write permission by reopening the file
with the p4 edit command. Downgrading causes any later
'p4 integrate -r' to want to merge the changes back into the
source file.
A branch view may be given directly on the command line by stating
the source (from) and target (to) files, or indirectly by naming
a stored branch view with -b branch. A stored branch view may have
many mappings, while a view on the command line can only have one.
If a stored branch view is given, the target files and source
files and revisions may be further limited on the command.
If no file specification is given then the entire branch view is
examined for needed integrations. If a file specification is
given, the integration is limited to only those target files.
In both cases, the integration is also limited to those target
files that are also in the client view.
If no revision specification is given then all revisions of the
source file are considered for integration. If a single revision
is given, then only revisions up to the given revision are included.
If a pair of revisions is given (separated by a comma (,)) then
only those revisions, inclusively, are integrated. Note that the
revision specification concerns the fromFile, but is attached to
the toFile. See 'p4 help revisions' for help specifying revisions.
The -f flag forces integrate to act without regard for previous
integration history. Normally, integrate skips any file revisions
already integrated. Note: unless revRange is given as well, the -f
flag will force p4 resolve perform merges without a common base.
To avoid this, use -f only to force integration of specific changes.
-f implies -i (below).
If -c changelist# is given, the files are opened in the numbered
pending changelist instead of the 'default' changelist.
The -d flag enables integrations around deleted revisions. If the
target file has been deleted and the source file has changed, -d
will re-branch the source file on top of the target file. If the
source file has been deleted and the target file has changed, -d
will delete the target file. Without -d, it refuses to mix
outstanding edits with a deleted file.
The -i flag enables baseless merges. When integrating into an
existing target file, 'p4 integrate' selects which revision p4
resolve uses as the base for its merge. That revision should be
the revision of the source file just before the first revision being
integrated. But if the first revision being integrated is the
revision at which the source file was added, which can happen if
there were no prior integrations between the source and target
files, then 'p4 integrate' refuses the baseless merge. The -i flag
forces 'p4 integrate' to schedule the merge, and p4 resolve then
uses the first, added revision as the base.
The -n flag displays what integrations would be necessary but does
not schedule them.
The -r flag reverses the mappings in the branch view, with the
target files and source files exchanging place. The -b branch flag
is required.
The -s fromFile[revRange] flag specifies the source (from) file.
It is used with the -b branch flag to limit the integrate to just
those selected source files. The integration is still limited to
any stated target (to) files on the command line. The -s flag also
causes the branch view to work bidirectionally, using the union of
the mappings and the reversed mappings. When the -s flag is used
the source revision range is attached to the source file, rather than
to the target files. Yes, this is confusing to code, too.
The -t flag makes the source file's filetype propagate to the target
file. Normally, the target file retain its previous filetype.
Newly branched files always use the source file's filetype. The
filetype can still be changed before p4 submit with p4 reopen
The -v flag makes 'p4 integrate' work faster by not copying newly
branched files to the client. In this case, the files can be
fetched with p4 sync after they are submitted with 'submit'.
[Note that this was the default behavior for newly branched files
in release 97.2 and earlier.]
Note: the syntax 'p4 integrate -b branch toFile[revRange]' is
provided for backwards compatibility, but is confusing because
it mixes the target file with the source revisions.