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

P4 CLI Reference | 2025.1

# 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 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 in the P4 CLI Documentation.

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

`-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