p4 integrate

Open files for branching or merging.

p4 integrate can be abbreviated as p4 integ.

Syntax

p4 [g-opts] integrate [options] fromFile[revRange] toFile
p4 [g-opts] integrate [options] -b branch [-r] [toFile[RevRange] ...]
p4 [g-opts] integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 [g-opts] integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]

For [options], you can use:

-c changelist  -Di  -f -h -O[b][r]  -n -m max -R[b][d][s] -q

Description

When you’ve made changes to a file that need to be propagated to another file, start the process with p4 integrate. The command includes four syntax variants, depending on whether the source and target files are specified using files, branches, or streams.

The simplest syntax variant is p4 integrate fromFiletoFile; this lets the versioning service know that changes in fromFile need to be propagated to toFile, and has the following effects:

If toFile does not yet exist, fromFile is copied to toFile, then toFile is opened for branch in the client workspace.
If toFile exists, and shares a common ancestor with fromfile as above, then toFile is opened for integrate. You can then use p4 resolve to propagate all of, portions of, or none of the changes in fromFile to toFile.

The p4 resolve command uses fromFile as theirs, toFile as yours, and the file with the most edits in common as the base.
If fromFile was deleted at its last revision (and all previous changes have already been integrated between fromFile and toFile), toFile is opened for delete in the client workspace.
Whether you move files using p4 move, or whether you use native OS commands to rename files within your workspace (using p4 reconcile or p4 status to update your changelist to reflect the moves you made), p4 integrate automatically detects these actions, adjusts the source-to-target mappings appropriately, and schedules a filename resolve for each remapped file pair.

(Some of the available options modify this behavior. See Options for details.)

The process is complete when you p4 submittoFile to the depot.

Note

If you integrate from a classic branch or other stream depot to a task stream, the files are not copied up to the parent unless they are edited and submitted first.

To specify multiple files, use wildcards in fromFile and toFile. Any wildcards used in fromFile must match identical wildcards in toFile. Perforce compares the fromFile pattern to the toFile pattern, creates a list of fromFile/toFile pairs, and performs an integration on each pair.

The syntax p4 integrate fromFilestoFiles requires you to specify the mapping between fromFiles and toFiles each time changes need to be propagated from fromFiles to toFiles. Alternatively, use p4 branch to store the mappings between fromFiles and toFiles in a branch view, and then use p4 integrate -b branchview whenever you need to propagate changes between fromFiles and toFiles.

By default, files that have been opened for branch or integrate with p4 integrate are read-only in the client workspace. You can edit these files before submitting them using p4 edit to reopen the file for edit.

Whenever a toFile is integrated from a fromFile, Perforce creates an integration record in its database that describes the effect of the integration. The integration record includes the names of the fromFile, and toFile, the revisions of fromFile that were integrated into toFile, the new revision number for toFile, and the action that was taken at the time of the integration. See p4 integrated for a full description of integration actions.

In most cases, p4 integrate performs a lazy copy; the contents of the file are not duplicated on the server, because the integration record contains sufficient information to reproduce the file. Integrations performed on temporary object files (+S and +Sn) do not produce a lazy copy; the integrated tempobj file consumes additional diskspace on the server.

Alternatives to p4 integrate include the following:

p4 populate to quickly branch files without opening them in a workspace.
p4 copy to open files to be copied without scheduling any resolves.
p4 merge to open files to be merged and schedule resolves for all changes.

Options

Because some of the integration options add complexity to the integration process, we’ve divided the options into Basic Integration Options and Advanced Integration Options.

Basic Integration Options

`-b branchname [toFiles ...]`	Integrate the files using the `sourceFile`/`targetFile` mappings included in the branch view of `branchname`. If the `toFiles` argument is included, include only those target files in the branch view that match the pattern specified by `toFiles`. If a revision range is supplied with `toFiles`, the range refers to source revisions, not target revisions.
`fromFilestoFiles`	`fromFiles` are called the source files; `toFiles` are called the target files. Any `toFiles` that `p4 integrate` needs to operate on must be included in the `p4 client` view.
`-n`	Display the integrations this command would perform without actually performing them.
`-c changelist`	Open the `toFiles` for `branch`, `integrate`, or `delete` in the specified pending changelist. If this option is not provided, the files are opened in the default changelist.
`-q`	Quiet mode; suppresses normal output messages about the list of files being integrated, copied, or merged. Messages regarding errors or exceptional conditions are displayed.
`g-opts`	See Global Options.

Advanced Integration Options

`-b branchname -s fromFile[revRange] [toFiles ...]`	In its simplest form, `p4 integrate -b branchname -s fromFile` allows you to integrate files using the source/target mappings included in the branch view of `branchname`, but include only those source files that match the patterns specified by `fromFile`. In its more complicated form, when both `fromFile` and `toFile` are specified, integration is performed bidirectionally: first, integration is performed from `fromFile` to `toFile`; then integration is performed from `toFile` to `fromFile`. This variation of `p4 integrate` was written to provide some needed functionality to graphical Perforce applications; it is unlikely that you’ll need to use this more complex form.
`-b branchname -r [toFiles ...]`	Reverse the mappings in the branch view, integrating from the target files to the source files.
`-Di`	The `-Di` option modifies the way deleted revisions are treated. If the source file has been deleted and re-added, revisions that precede the deletion will be considered to be part of the same source file. By default, re-added files are considered to be unrelated to the files of the same name that preceded them. This flag is intended to be used for the documented purposes only, otherwise it might produce unintended integration results. For example, using the `-Di` option when a source file has been moved or renamed will not propagate the moved file correctly. The move/add and move/delete revisions are propagated as `branch` and `delete` revisions instead.
`-f`	Force the integration on all revisions of `fromFile` and `toFile`, even if some revisions have been integrated in the past. Best used with a revision range.
`-h`	Don’t automatically sync target files to the head revision before integrating. Use the have revision instead.
`-m max`	Limit the command to integrating only the first `max` files.
`-Ob`	The `-Ob` option outputs the base revision for the merge (if any).
`-Or`	The `-Or` option outputs the resolves that are being scheduled.
`-Rb`	The `-Rb` option schedules a branch resolve instead of branching the target files automatically.
`-Rd`	The `-Rd` option schedules a delete resolve instead of deleting the target files automatically.
`-Rs`	The `-Rs` option skips cherry-picked revisions that have already been integrated. Using this option can improve merge results, but can also cause multiple resolves per file to be scheduled.
`-S stream [-P parent]`	Integrates a stream to its parent. To reverse the direction of the mapping, use the `-r` option. To override the configured parent and integrate to a different target stream, specify `-P`. To submit integrated stream files, the current client must be switched to the target stream or to a virtual child stream of the target stream.

Usage Notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
Yes	Yes	`open`

Examples

`p4 integ //depot/dev/... //depot/rel2/...`	Branch or merge all files in `//depot/dev/...` to the corresponding files in `//depot/rel2/...` If there is no corresponding file in `//depot/rel2/...`, this creates it.
`p4 integ -b rel2br`	Branch or merge all `fromFiles` contained in the branch view `rel2br` into the corresponding `toFiles` as mapped through the branch view.
`p4 integ -b rel2br //depot/rel2/headers/...`	Branch or merge those `fromFiles` contained in the branch view `rel2br` that map to the `toFiles//depot/rel2/headers/...`
`p4 integ -b rel2br -r //depot/rel2/README`	Branch or merge `fromFile//depot/rel2/README` from its `toFile` as mapped through the branch view `rel2br`.

Related Commands

To create or edit a branch mapping	`p4 branch`
To view a list of existing branch mappings	`p4 branches`
To view a list of integrations that have already been performed and submitted	`p4 integrated`
To propagate changes from one file to another after opening files with `p4 integrate`	`p4 resolve`
To view a history of all integrations performed on a particular file	`p4 filelog`