NAME

SYNOPSIS

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

DESCRIPTION

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.

OPTIONS

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

BRANCHES

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 "branch_id"s 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".

LIMITATIONS

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.

SEE ALSO

AUTHOR

COPYRIGHT

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