p4 populate

Branch 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 new files are created immediately, without requiring a p4 submit or a client workspace.

Tip

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 Helix Core Server Administrator Guide.

If the p4 populate command fails after the change-content stage succeeds, a change-fail trigger is enabled. See "Triggering On Submits" in the Helix Core Server Administrator Guide.

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

Note

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