VCP::Source::p4 - A Perforce p4 repository source
vcp p4://depot/...@10 # all files after change 10 applied
vcp p4://depot/...@1,10 # changes 1..10
vcp p4://depot/...@-2,10 # changes 8..10
vcp p4://depot/...@1,#head # changes 1..#head
vcp p4://depot/...@-2,#head # changes 8..10
vcp p4:...@-2,#head # changes 8..10, if only one depot
To specify a user name of 'user', P4PASSWD 'pass', port 'host:1666', and p4
client 'client' use this syntax:
Or, to run against a private p4d in a local directory, use this syntax and the
Note: VCP will set the environment variable P4PASSWD rather than sending the
password to p4 via the command line, so it shouldn't show up in error
messages. This means that a password specified in a P4CONFIG file will
override the one set on the VCP command line. This is a bug. User, client and
the server string will be passed as command line options to make them show up
in error output.
You may use the P4... environment variables instead of any or all of the fields
in the p4: repository specification. The repository spec overrides the
If the P4::Client Perl module is installed, this will be used instead of the p4
command line utility. If this causes undesirable results, set the environment
variable VCPP4API equal to "0" (zero).
Driver to allow vcp to extract files from a Perforce
Note that not all metadata is extracted: users, clients and job tracking
information is not exported, and only label names are exported.
Also, the 'time' and 'mod_time' attributes will lose precision, since p4 doesn't
report them down to the minute. Hmmm, seems like p4 never sets a true
mod_time. It gets set to either the submit time or the sync time. From
"p4 help client":
modtime Causes 'p4 sync' to force modification time
to when the file was submitted.
nomodtime * Leaves modification time set to when the
file was fetched.
See also the OPTIONS sections in VCP::Source and "OPTIONS" in
- Runs a p4d instance in the directory indicated by repo_server (use a
directory path rather than a host name). If repo_server contains a port,
that port will be used, otherwise a random port will be used.
Dies unless the directory exists and contains files matching db.* (to help
prevent unexpected initializing of empty directories).
VCP will kill this p4d when it's done.
- Causes VCP to notice "branch into" messages in the output of
p4's filelog command and. If the file that's the target of the p4
integrate (branch) command is revision number #1, adds the target to the
list of exported files. This usually needs a --rev-root option to set the
rev root to be high enough in the directory tree to include all branches
(it's an error to export a file that is not under the rev root).
- Sets the "revisions" root of the source tree being extracted;
without this option, VCP assumes that you are extracting the directory
tree ending in the last path segment in the filespec without a wildcard.
This allows you to specify a shorter root directory, which can be useful
especially with --follow-branch-into, since branches may often lead off
from the current directory to peer directories or even in to entirely
The default "rev-root" is the file spec up to the first path
segment (directory name) containing a wildcard, so
would have a rev root of "/a/b".
In direct repository-to-repository transfers, this option should not be
necessary, the destination filespec overrides it.
VCP uses the "directory" name of each file as the file's branch_id.
VCP ignores p4 branch specs for several reasons:
- Branch specs are not version controlled, which means that you can't tell
what a branch spec looked like when a branch was created.
- Multiple branch specs can point to the same directory or even the same
- branch specs are not necessary in managing a p4 repository.
TODO: build a filter or VCP::Source::p4 option that allows p4 branch
specifications to determine branch_ids.
As the VCP Branches chapter mentions, you can use a Map section in the transfer
specification to extract meaningful "branch_id"s if you need to.
- The p4 client name. This is an accessor for a data member in each class.
The data member should be part of VCP::Utils::p4, but the fields pragma
does not support multiple inheritance, so the accessor is here but all
derived classes supporting this accessor must provide for a key named
Treats each branched file as a separate branch with a unique branch_id, although
files that are branched together should end up being submitted together in the
destination repository due to change number aggregation.
Ignores branch specs for now. There may be an option to enable automatic use of
branch specs because most are probably well behaved. However, in the event of
a branch spec being altered after the original branch, this could lead to odd
results. Not sure how useful branch specs are vs. how likely a problem this is
to be. We may also want to support "external" branch specs to allow
deleted branch specs to be used.
VCP::Source::p4 only emits "add", "branch",
"delete" and "edit" actions; this is all most destinations
can handle today. Anything other than one of these four is converted to
"edit". Specifically, this means that when an integration into a
file is found, this is treated as an edit. Transferring integration records
that don't create branches is not implemented.
p4 servers older than 2002.2 do not allow getting the submit date and time, only
the submit *date*, so all changes will seem to happen at midnight. Upgrate to
the most recent p4d to solve this.
Barrie Slaymaker <email@example.com>
Copyright (c) 2000, 2001, 2002 Perforce Software, Inc. All rights reserved.