      |
|
Update the client workspace to reflect the contents of the depot.
This command behaves differently when syncing a client workspace that
maps files from a depot of type graph. See
Working with a depot of type graph.
p4 [g-opts] sync [-f -k -L -n -N -q -r] [-m max] [file [revRange] ...]
p4 [g-opts] sync [-L -n -N -q -s] [-m max] [file[revRange] ...]
p4 [g-opts] sync [-L -n -N -p -q] [-m max] --parallel=threads=n[,batch=n][,batchsize=n][,min=n][,minsize=n [file[revRange] ...]
p4 sync brings the client workspace into sync with
the depot by copying files matching its file pattern arguments from the
depot to the client workspace. When no file patterns are specified on the
command line, p4 sync copies a particular depot file
only if it meets all of the following criteria:
p4
edit, p4
delete, p4
add, or p4
integrate;In new, empty workspaces, all depot files meet the last two criteria, so all the files visible through the workspace view are copied into the user’s workspace.
If file patterns are specified on the command line, only those files that match the file patterns and that meet the above criteria are copied.
If the file pattern contains a revision specifier, the specified revision is copied into the client workspace.
If the file argument includes a revision range, only files included in
the revision range are updated, and the highest revision in the range is
used. Files that are no longer in the workspace view are not affected if
the file argument includes a revision range. Use p4 help
revisions to get help about specifying revisions.
The p4 sync command automatically resolves files
where the previously synced version does not differ from the newer depot
version. Any files you have open when you run p4
sync, will need to be manually resolved using the p4 resolve command.
Newly synced files are read-only; p4
edit and p4
delete make the files writable. Do not use your
operating system’s commands to make the files writable; instead, use
Perforce
to do this for you.
|
|
Force the sync. Perforce performs the sync even if the client workspace already has the file at the specified revision. If the file is writable, it is overwritten. This option does not affect open files, but it does
override the |
|
|
Keep existing workspace files; update the have list without
updating the client workspace. Use
If your administrator has set the |
|
|
For scripting purposes, perform the sync on a list of valid file arguments in full depot syntax with a valid revision number. When this flag is used, the arguments are processed together by building an internal table similar to a label. This file list processing is significantly faster than having to call the internal query engine for each individual file argument. However, the file argument syntax is strict and the command will not run if an error is encountered. |
|
|
Sync only the first |
|
|
Preview mode: Display the results of the sync without actually performing the sync. |
|
|
Preview mode: Display a summary of the expected network traffic associated with a sync, without performing the sync. This tells you how many files are to be added or updated, which is useful if you’re dealing with many large files and/or are bandwidth or diskspace-limited. This option is useful for estimating network impact of a sync before attempting to perform the sync. If you’ve recently updated your client workspace view, it’s useful to know if you have inadvertently included a folder tree that holds several gigabytes of assets before attempting to sync your newly-configured workspace. |
|
|
Populate a client workspace, but do not update the have list. Any file that is already synced or opened is bypassed with a warning message. This option is typically used for workspaces used in processes (such as certain build or publication environments) where there is no need to track the state of the workspace after it has first been synced. |
|
|
Specify options for parallel file transfer. The configuration
variable
See Parallel processing for more information. |
|
|
Quiet operation: suppress normal output messages. Messages describing errors or exceptional conditions are not suppressed. |
|
|
Reopen files that are mapped to new locations in the depot, in the new location. By default, open workspace files remain associated with the depot files that they were originally opened as. For example, pending work can be moved to a different stream by
running |
|
|
Safe sync: Compare the content in your client workspace against what was last synced. If the file was modified outside of Perforce control, an error message is displayed and the file is not overwritten. If your client workspace specification has both the
|
|
|
See Global Options. |
| Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
|---|---|---|
|
Yes |
Yes |
|
If the client workspace view has changed since the last sync, the next sync removes from the client workspace those files that are no longer visible through the workspace view (unless a revision range is used), and copies into the client workspace those depot files that were not previously visible.
By default, any empty directories in the workspace are cleared of
files, but the directories themselves are not deleted. To remove
empty directories upon syncing, turn on the rmdir option
in the p4 client
form.
If a user has made certain files writable by using OS commands
outside of
Perforce’s
control, p4 sync will not normally overwrite
those files. If the clobber option in the p4 client form has
been turned on, however, these files will be overwritten.
You can prevent this behavior (at a minor cost in performance) by
using the -s "safe sync" option. Even if the
clobber option is set, p4 sync -s
will not overwrite files modified outside of
Perforce
control.
p4 sync if
you request it with p4 -I sync -q.p4 sync
with multiple arguments referencing the same file multiple times, as in
this example: p4 sync depot/project/...@1000
//depot/project/file.txt@1010. Doing so will result in
unpredictable, inconsistent revisions.The -m max option is useful when combined with the
-n option for efficient scripting. For example, a command
like p4 sync -n -m 1 does not sync any files, but
displays only one line of output if there are any files to be synced, or
a message indicating that the workspace is up to date. Without the
-m 1 option, the output could conceivably be thousands of
lines long, all of which would be discarded.
The -L option is intended for use by scripts or automated
reporting processes. File arguments must be in full depot syntax, and
have a valid revision number. File specifications that do not meet these
requirements are silently ignored. Using this option speeds up file list
processing.
Depending on the number of files being transferred, the p4
sync command might take a long time to execute. You can
speed up processing by having this command transfer files using multiple
threads. You do this by setting the net.parallel.max
configuration variable to a value greater than one and by using the
--parallel option to the p4 sync
command. Parallel processing is most effective with long-haul, high
latency networks or with other network configuration that prevents the
use of available bandwidth with a single TCP flow. Parallel processing
might also be appropriate when working with large compressed binary
files, where the client must perform substantial work to decompress the
file.
To configure parallel processing, set the net.parallel.max
configuration variable to a value greater than one and use the
--parallel option to the p4 sync
command.
net.parallel.max configuration variable can be set
to any value between 0 and 100. A value of 0 or 1 disables parallel
processing. A value greater than 1 enables parallel processing up to
the specified level. So if you want to set the --parallel
option to 12, the net.parallel.max variable must be set to
at least 12.The --parallel option allows you to specify how the
parallel processing is to be done. You can specify the suboptions in
any order.
Use the min and/or minsize suboptions to
indicate that you don’t want parallel processing unless the sync
involves sending at least min number of files or at
least minsize number of bytes.
Use the batch and/or batchsize suboptions
to specify how many files or bytes should be taken at a time. Setting
the batch size small should result in the best use of the network at
the risk of overloading database resources.
If the net.parallel.max configuration variable is not set
or if the requested number of parallel threads exceeds the value set for
net.parallel.max, the command will execute without using
parallel threads or will use the maximum number of allowed threads.
You can also control parallel processing behavior using the following
configurables: net.parallel.batch,
net.parallel.batchsize, net.parallel.min,
net.parallel.minsize, and net.parallel.threads.
This sets behavior globally and can be overridden for a given p4
sync command if that command specifies different parallel
processing option values.
If your client workspace is dynamically-generated because your client
workspace’s Stream: field is set to a valid stream, and you
have also set the StreamAtChange: field to point to a
specified changelist number, p4 sync, when called
with no arguments, will sync your workspace to the revisions of files
available as of that changelist, using the client workspace that
corresponds to the corresponding stream specification at that point in
time.
You can sync a client that has a view spec that maps files in a repo. If
you do not specify a branch in the repo, p4 sync
defaults to the master branch of the repo. If the client
spec maps both a classic depot and a depot of type graph,
p4 sync updates the client workspace for both types
of depots. To sync a repo branch or a SHA-1, see the final three examples
in the section
Examples.
For more information about depots of type graph, see the
section
Including Graph Depots repos in your client
in the topic p4 client
and the section
Working with depots of type graph
in the topic p4
depot.
Over unreliable networks, you can specify the number of retries to
attempt and the length of time beyond which the
Perforce
application assumes that the network has timed out. Set
net.maxwait in your workspace’s P4CONFIG file or on a one-command
basis from the command line, and specify the number of retries with
-r n, where n is the number of times to
attempt reconnection.
The command below attempts to sync the user’s workspace, making up to three attempts to resume the sync if interrupted. The command fails after the third 60-second timeout.
$ p4 -r3 -vnet.maxwait=60 sync
Because the format of the output of a command that times out and is
restarted cannot be guaranteed (for example, if network connectivity is
broken in the middle of a line of output), avoid the use of
-r on any command that reads from standard input.
|
|
Copy the latest revision of all files from the depot to the client workspace, as mapped through the client view. If the file is already open in the client workspace, or if the latest revision of the file exists in the client workspace, it is not copied. |
|
|
Copy the fourth revision of |
|
|
Copy all the files under the Don’t copy the latest revision; use the revision of the file in the depot after changelist 21 was submitted. |
|
|
If Files listed in Files not listed in |
|
|
Bring the workspace into sync with a label as with (The revision range
|
|
|
Bring the workspace into sync with the depot as of midnight, June 24, 2011. (That is, include all changes made during June 23.) |
|
|
Sync a filename containing a
Perforce
wildcard by using the ASCII expression of the character’s
hexadecimal value. In this case, the file in the client workspace
is For details, see Limitations on characters in filenames and entities. |
|
|
Sync to the nonexistent revision of |
|
|
Sync to the nonexistent revision of all files; all files in the workspace (that are under Perforce control) are removed. |
|
|
For a repo in a depot of type |
|
|
For a repo in a depot of type |
|
|
For a repo in a depot of type |
|
To open a file in a client workspace and list it in a changelist |
|
|
To copy changes to files in the client workspace to the depot |
|
|
To view a list of files and revisions that have been synced to the client workspace |
| |
|