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 Helix Swarm with the projects they are part of, add the 'branch' paths in the Swarm project. (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`