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 CWp4 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 VCP::Driver.

--run-p4d

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.

--follow-branch-into

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).

--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 different trees. The default CWrev-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 CW/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:

1

Branch specs are not version controlled, which means that you can't tell what a branch spec looked like when a branch was created.

2

Multiple branch specs can point to the same directory or even the same file.

3

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 CWbranch_ids if you need to.

repo_client

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 P4_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.

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.

VCP::Dest::p4, vcp.

Barrie Slaymaker <barries@slaysys.com>

Copyright (c) 2000, 2001, 2002 Perforce Software, Inc. All rights reserved.

See VCP::License (CWvcp help license) for the terms of use.