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

P4 CLI Documentation | 2025.2

# p4 populate

Branch (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. a set of files as a one-step operation.

## Syntax

    p4 [g-opts] populate [-d description] [-f -n -o] [-m max] fromFile[rev] toFile

    p4 [g-opts] populate [-d description] [-f -n -o] [-m max] -b branch [-r]
                         [toFile[rev]]

    p4 [g-opts] populate [-d description] [-f -n -o] [-m max] -b branch -s fromFile[rev]
                         [toFile]

    p4 [g-opts] populate [-d description] [-f -n -o] [-m max] -S stream [-P parent] [-r]
                         [toFile[rev]]

Syntax and naming conventions

## Description

The `p4 populate` command branches a set of files (the source) into another depot location (the target) in a single step. The branched files are available, without requiring a `p4 submit` or a client workspace.

Do not run `p4 populate` on a newly-created sparse stream because a sparse stream should only branch a small number of files from its parent stream. To learn more, see Sparse streams.

The dm.populate.skipkeyed configurable might improve performance for this command.

The execution of the `p4 populate` command fires a `change-submit` trigger to allow interested parties to perform a check or validation before submission. The value of the `rpl.checksum.change` configurable determines the level of verification performed for this command. See Change-submit triggers in the P4 Server Administration Documentation.

If the `p4 populate` command fails after the `change-content` stage succeeds, a `change-failed` trigger is enabled. See Change-content triggers and Change-failed triggers in the P4 Server Administration Documentation.

Similar to the pending changelist of a `change-content` trigger, a change-submit temporary pending change record is created so that the changelist description can be accessed.

Unlike standard change-submit triggers that have access to the files in the changelist being submitted, a change-submit trigger fired by p4 populate only has access to the changelist metadata if you use the following command,

p4 describe -s changelist

the output of which includes changelist metadata but not the list of files.

To get a list of the files involved in a populate trigger script, use a change-content trigger, which provides access to the files in the changelist if you use the p4 files @=changelist command, such as p4 files @=14 where 14 represents the changelist number. Because there is no file transfer from the client with the populate command, a change-content trigger is equivalent to a change-submit trigger.

To determine when a `p4 populate` command fires a change-submit or change-content trigger, as well as which arguments were passed to the `p4 populate` command, pass %command% and %argsQuoted% to a change-submit or change-content trigger.

## Options

Option | Description
--- | ---
`-b branch` | Use the view in a user-defined `branch` specification. The source is the left side of the branch view and the target is the right side of the branch view.
`-d description` | Provide a description for the automatically-submitted changelist. If no description is provided, the command line arguments are used for a description.
`-f` | Force deleted files to be branched into the target. (By default, deleted files are treated as nonexistent and are skipped.)
`-m max` | Limit the action to the first `max` files.
`-n` | Preview the operation without actually doing anything.
`-o` | Display a list of files created by the `p4 populate` command.
`-P parent` | When used with `-S stream`, specify a parent stream other than the stream’s actual parent.
`-r` | Reverse direction of integration (from target to source, rather than from source to target).
`-s` | If used with `-b branch`, treat `fromFile` as the source, and use both sides of the user-defined branch view as the target. Optional `toFile` arguments can be given to further restrict the scope of the target file set. The `-r` option is ignored when `-s` is used.
`-S stream` | Use a stream’s view; the source is the stream itself, and the target is the stream’s parent.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
Yes | No | `write`

Your search for returned results