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