Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Reference | 2025.1

# p4 integrate

Open files and/or the stream spec for branching (noun) A set of related files that exist at a specific location in the P4 depot as a result of being copied to that location, as opposed to being added to that location. A group of related files is often referred to as a codeline. To associate code reviews in P4 Code Review (formerly Helix Swarm) with the projects they are part of, add the 'branch' paths in the P4 Code Reviewproject. (verb) To create a codeline by copying another codeline with the 'p4 integrate', 'p4 copy', or 'p4 populate' command. or merging.

p4 integrate can be abbreviated as `p4 integ`.

## Syntax

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

For [options], you can use:

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

For streams, you can use:

    p4 integrate -S stream [-As | -Af]

Syntax conventions

## 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 fromFile toFile`, which 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 Options modify this behavior.

The process is complete when you `p4 submit` `toFile` to the depot.

If you integrate from a non-stream depot branch or from 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`. P4 Server compares the `fromFile` pattern to the `toFile` pattern, creates a list of `fromFile` and `toFile` pairs, and performs an integration on each pair.

The syntax `p4 integrate fromFiles toFiles` 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`, P4 Server 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 A method to conserve disk space by referencing files instead of duplicating their content.. The contents of the file are not duplicated to multiple locations on the server because the integration record contains sufficient information to reproduce the file.

### Alternatives to `p4 integrate`

- p4 populate to quickly branch files without opening them in a workspace
- p4 copy to open files to be copied without scheduling any resolves. Consider whether the `-v` option of `p4 copy` is appropriate for your use case.
- p4 merge to open files to be merged and schedule resolves for all changes

## 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.
`fromFiles` `toFiles` | 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.
`-v` | Performs a "virtual" integration that does not modify client workspace files unless target files need to be resolved. After submitting a "virtual integration", p4 sync can be used to update the workspace.
`-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, which 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 in two steps: From `fromFile` to toFile From `toFile` to fromFile This variation of `p4 integrate` was written to provide some needed functionality to graphical P4 Server 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. When the source file has been moved or renamed, 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.
`-K` | Suppress keyword expansion when updating `+k` type files on the client. See File type modifiers.
`-m max` | Limit the command to integrating only the first `max` files.
`-Ob` | The `-Ob` option outputs the base 1. For files: The file revision that contains the most common edits or changes among the file revisions in the source file and target file paths. 2. For checked out streams: The public 'have' version from which the checked out version is derived. See also 'have list'. 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. Integrates both the files and the stream spec unless you use `-Af` to integrate the files only, or `-As` to integrate the stream spec only.

## 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`.
p4 integ -r -As -S //str/dev3 | Perform a stream spec integration onto //str/dev3 from its parent stream. This might be useful if //str/dev3 has a ParentView of noinherit and otherwise would not be affected by its parent stream.

## Related commands

Create or edit a branch mapping | `p4 branch`
View a list of existing branch mappings | `p4 branches`
Branch a set of files as a one-step operation | `p4 populate`
View a list of integrations that have already been performed and submitted | `p4 integrated`
Propagate changes from one file to another after opening files with `p4 integrate` | `p4 resolve`
View a history of all integrations performed on a particular file | `p4 filelog`

Your search for returned results