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:
vcp p4:user(client):pass@host:1666:files
Or, to run against a private p4d in a local directory, use this syntax and the --run-p4d option:
vcp p4:user(client):pass@/dir:files vcp p4:user(client):pass@/dir:1666:files
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 environment variables.
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 repository.
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 VCP::Driver/OPTIONS.
--run-p4d
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.
--follow-branch-into
--rev-root
The default rev-root
is the file spec up to the first path segment
(directory name) containing a wildcard, so
p4:/a/b/c...
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 file.
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.
repo_client
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.
Barrie Slaymaker <barries@slaysys.com>
Copyright (c) 2000, 2001, 2002 Perforce Software, Inc. All rights reserved.
See VCP::License (vcp help license
) for the terms of use.